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ABSTRACT 



A full-featured e-mail system is used in both Internet-based 
and client-side (personal computer) forms. In each form, 
either basic e-mail service is provided to system subscribers 
or a secure, premium service with authentication . 
concealment integrity, and non-repud iation functions for 
electronic messaging services is provided. In either form and 
at either level of service, subscribers can work off-line on 
their own computers with proprietary software loaded or, 
alternatively, on-line on any computer with an Internet 
connection. The system is interoperable, to preserve 
security, with all S/MIME compliant software applications, 
even for those users not subscribing to a service implement- 
ing the disclosed system. Digital certificates can be provided 
as a security service of the disclosed system, rather than 
requiring a second source with separate verification proce- 
dures. As additional optional features, the subscriber can 
control compression of outgoing attachment files, rather 
than having that function absent or operate in some auto- 
matic way. Decompression of such file attachments when 
received occurs automatically for subscribers, without hav- 
ing to invoke a different program or system. Interactive help 
features, book hierarchy uniformity for messages, accounts, 
certificates, virus warnings, and dual naming capability are 
also provided and available to subscribers in both the 
Web-based and the client-side application forms disclosed 
herein, and in both basic and premium service levels. 

10 Claims, 8 Drawing Sheets 



User A 
(Subscriber) 



Computer X 



ITER NET - 




SERVER 111 
(w/ SMIME) 



Computer A 
(w/ EMC) J 



SERVER I 
(w/ EMC) 



J 



SERVER II 
(w/EMC) 



A Computer B 
__n (w/EMC) J 



i- C 



User 8 
(Subscriber) J 



Computer Y 



Computer C 



Computer 2 U- 



01/05/2004, EAST version: 1.4.1 



U.S. Patent Mar. 12,2002 Sheet 1 of 8 US 6,356,937 Bl 



r User A ^ 


^ (Subscriber)^ 




r 




\ 


Computer X 


v 


J 



Computer A 
(w/ EMC) 












SERVER 1 






(w/ EMC) 











SERVER II 
(w/EMC) 



Computer B 
(w/ EMC) 



1 



User B 
(Subscriber) 



Compuier Y M- 



SERVER III 
(w/ SMI ME) 



Computer C 



1 



User C 



Computer Z 



Fig. 1 



01/05/2004, EAST Version: 1.4.1 



U.S. Patent Mar. 12, 2002 Sheet 2 of 8 US 6,356,937 Bl 



FIG. 2 



MAIL SERVER ARCHITECTURE 



DHTML/ 
HTML 



BROWSER 
VERSION 3.0+ 



HTTP/SSL 



JAVA 
APPLICATION 



TCP/IP 

JAVA SERVLET API2.IJ 
JDK 1 2 

JCE ' 2 / WEB/ 

JAFI.0 APPLICATION I 

JAVAMAILH \ SERVER 



JAVA SERVLETS 




JDK 1 2 
JFC SWING 
JCE 1 2 
JAFI.0 
JAVA MAIL 1 1 
JAVAHELPI.0 



01/05/2004, EAST Version: 1.4.1 



U.S. Patent Mar. 12, 2002 Sheet 3 of 8 US 6,356,937 Bl 



FIG. 3 




FIG. 4 




01/05/2004, EAST version: 1.4.1 



U.S. Patent Mar. 12, 2002 Sheet 4 of 8 US 6,356,937 Bl 



FIG. 5 



E-MAILCOP 



FILE AEORESS BOOK ACCOUNT BOOK HELP 



CREATE 



SEND 



RETRIEVE 
MESSAGES 



□ ENCRYPT 

□ SIGN 

□ COMPRESS 



SO ACCOUNT BOCK 
I O AOORESS BOOK 

T] O MESSAGE BOOK 



APPLICATION 
LOGO IS PLACED 
HERE 



HNTERACTIVE HELP PANEL- 



FIG. 6 



E-MAILCOP 



FILE ADDRESS BOOK ACCOUNT BOOK HELP 



CREATE 



SEND 



RETRIEVE 
MESSAGES 



D ENCRYPT 

□ SIGN 

□ COMPRESS 



O ACCOUNT BOOK 
O ADORESS BOOK 
O MESSAGE BOOK 



FOLDER COMPRESSION/DECOMPRESSION 

TO COMPRESS A FOLDER, FIRST HIGHLIGHT THE FOLDER 
FROM THE LIST DISPLAYYaT RIGHT) THEN SELECT THE 
'ARCHIVE" BUTTON BELOW. 

TO DECOMPRESS A FXDERFIRST HIGHLIGHT THE 
FOLDER FROM THE ARCHiVfe UST (SHOWN 8ELOW). 
THEN SELECT THE "DECOMPRESS BUTTON BELOW. 

WHEN YOU ARE FINISHED USING THE ARCHIVE TOOL, 
SELECT THE "DONE BELOW TO RETURN TO THE 
PREVIOUS SCREEN. 



r ARCHIVE LIST- 



ARCHIVE 
DECOMPRESS 
DONE 



INTERACTIVE HELP PANELn 



01/05/2004, EAST version: 1.4.1 



U.S. Patent Mar. 12, 2002 Sheet 5 of 8 US 6,356,937 Bl 



FIG. 7 



E-MAILCOP 



FILE ADDRESS BOOK ACCOUNT BOOK HELP 





CREATE 


SEND 


RETRIEVE 
MESSAGES 



□ ENCRYPT 

□ SIGN 

□ COMPRESS 



O ACCOUNT BOOK 
O ADDRESS BOOK 
O MESSAGE BOOK 



r— PREFERENCE SETTINGS - 



OUTGOING MESSAGE SETTINGS 

□ ENCRYPT OUTGOING MESSAGES 

□ SIGN OUTGOING MESSAGES 

□ COMPRESS OUTGOING MESSAGES 

□ APPEND SIGNATURE FILE 

□ INCLUDE ORIGINAL MESSAGE IN REPLY 

MISCELLANEOUS SETTINGS 

□ ENABLE VACATION REPLY 

□ ENABLE INTERACTIVE HELP PANEL 
I RESET INTERACTIVE HELP PANEL | 



CHOOSE THE CHECK 
BOXES AT LEFT TO 
SET YOUR PREFER- 
ENCES THEN 
SELECT "DONE 
BELOW. 



DONE 



NTERACTIVE HELP PANEL - ! 



FIG. 8 

IE-MAILCOP 



mm 



FILE ADDRESS BOOK ACCOUNT BOOK HELP 





CREATE 


SEND 


RETRIEVE 
MESSAGES 



□ ENCRYPT 

□ SIGN 

ncavPRESs 



CAS [PEOPLE YOURS I CRL 



-CERTIFICATE BOOK 

HERE YOU CAN VIEW CERTIFICATES FOR YOUR RECOGNIZED 
CERTIFICATION AUTHORITIES.YOUR CORRESPONDENTS 
CERTIFICATES, AND YOUR CERTIFICATE. 

TO VIEW AN INDIVIDUAL 
CERTIFICATE FIRST 
HIGHLIGHT THE CERTIF- 
ICATE IN THE BOX AT 
LEFT, THEN CLICK THE 
VIEW BUTTON. 

TO REVOKE (DISCONTIN 
UE USE OF] A CERTIF- 
ICATE, FIRST HK5HUGHT 
THE CERTIFICATE IN 
THE BOX AT UEFT, 
THEN CLICK THE 
'REVOKE" BUTTON. 

TO EXIT, CLICK "DONE" 



O ACCOUNT BOOK 
O ADDRESS BOOK 
O MESSAGE BOOK 



a 



I VIEW | REVOKE] 



DONE 



INTERACTIVE HELP PANEL- 



01/05/2004, EAST Version: 1.4.1 



U.S. Patent Mar. 12, 2002 Sheet 6 of 8 



US 6,356,937 Bl 



FIG. 9 



□EB3I 



E-MAILCOP 



FILE ADDRESS BOOK ACCOUNT BOOK HELP 



CREATE 



SEND 



RETRIEVE 
MESSAGES 



□ ENCRYPT 

□ SIGN 

□ COMPRESS 



O ACCOUNT BOOK 
O ADDRESS BOOK 
O MESSAGE BOOK 



rFILTER SETTINGS - 
NAME | 



F THE iTO: j»| F1ELDCCN1ANS[ 



THEN MOVE MESSAGE TO |<SELECT R)LDER> H 



TO ADD ANEW RLTERJYPE THE NAME OF THE FILTER, 
SELECT THE FELD TO CHECK, TYPE THE STRING TO BE 
FOUND N THAT FELD, SELECT THE FOLDER IN WHICH 
TO PLACE THE MESSAGES, THEN CLICK THE "ADD" 
BUTTON BELOW. 

TO DELETE A FIUER,SELECT THAT FILTER FROM THE 
LIST AT RIGHT, THEN CLICK THE "DELETE BUTTON. 

WHEN YOU ARE FINISHED EDITING 
YOUR MAIL FILTERS, CLICK "DONE" 
TO RETURN TO THE PREVIOUS 
SCREEN. 



ADO| DELETE | DONE | 



INTERACTIVE HELP PANEL 



FIG. 10 



E-MAILCOP 



umm 



FILE ADDRESS BOOK ACCOUNT BOOK HELP 



CREATE 



SEND 



RETRIEVE 
MESSAGES 



□ ENCRYPT 

□ SIGN 

□ COMPRESS 



ADDRESS BOOK 

TO ADD AN ADDRESS. ENTER 
THE INFORMATION IN THE TEXT 




O ACCOUNT BOOK 
O ADDRESS BOOK 
O MESSAGE BOOK 



NAME 



BOXES, SELECT A FOLDER 
FROM THE PULL DOWN MENU, 
THEN SELECT THE "ADD TO" 
BUTTON. 

TO DELETE AN ADDRESS OR 
ADDRESS FOLDER. SELECT 
THAT ADDRESS Orf FOLDER 
FROM THE ADDRESS BOOK 
DISPLAY. THEN SELECT THE 
"DELETE BUTTON. 
WHEN YOU ARE FINISHED EDIT- 
ING THE ADDRESS BOOK. 
SELECT THE "DONE" BUTTON 

TO RETURN TO THE . . _ 

PREVIOUS SCREEN. 1 ADD TO) < SELECT FOLDER >| V j 



E-MAIL 
PHONE 
FAX 

STREET 



crrY£ 



STATE 



□ 



ZIP 



DELETE 



DONE 




01/05/2004, EAST version: 1.4.1 



U.S. Patent Mar. 12, 2002 Sheet 7 of 8 US 6,356,937 Bl 



FIG. 



E-MAILCOP 



FILE ADDRESS BOOK ACCOUNT BOOK HELP 



CREATE 



SEND 



RETRIEVE 
MESSAGES 



□ENCRYPT 
□ SIGN 
□COMPRESS 



(ACCOUNT BOOK 

TO ADD NEW ACCOUNT, ENTER 
THE CORRECT INFORMATION IN 
THE TEXT BOXES,SEL£CT A 
FOIDER FROM THE PUU DOWN 
MENU, THEN CLICK THE 
"ADD TO" BUTTON. 




O ACCOUNT BOOK 
O ADDRESS BOOK 
O MESSAGE BOOK 



USER NAME I 
PASSWORD [ 

SERVER NAME [ 



□ SET AS A DEFAULT ACCOUNT 

i 



TO DELETE AN ACCOUNT OR 

ACCOUNT FOLD£R,HIGHLIGHT 

THAT ACCOUNT OR FOLDER IN lADOTOhSELECT FOLDER> 
THE ACCOUNT BOOK .THEN 1 ^ 1 
CLICK THE^DELEIE*' BUTTON. 

WHEN YOU ARE FINISHED 
ENDING THE ACCOUNT BOOK 
YOU MAY EXIT BY CLICKING 
THE "DONE" BUTTON. 



DELETE 



DONE 



INTERACTIVE HELP PANEL-. 



FIG. 12 



E-MAIICOP 



QUE) 



FILE ADDRESS BOOK ACCOUNT BOOK HELP 





CREATE 


SEND 


RETRIEVE 
MESSAGES 



□ENCRYPT 

□ SIGN 

□ COMPRESS 



TUTORIAL- 




O ACCOUNT BOOK 
O ADDRESS BOOK 
O MESSAGE 800K 



BACK FORWARD 



EXIT 



^INTERACTIVE HELP PANEL — \ 



01/05/2004, EAST Version: 1.4.1 



U.S. Patent Mar. 12, 2002 Sheet 8 of 8 US 6,356,937 Bl 



FIG. 13 



E-MAiLCOP 



FILE ADDRESS BOOK ACCOUNT BOOK HELP 





CREATE 


SEND 


RETRIEVE 
MESSAGES 



r COMPOSER - 



□ SIGN 

□ COMPRESS 



O ACCOUNT BOOK 
O ADDRESS BOOK 
O MESSAGE BOOK 



ATTACH | SAVE | SIGNATURE SPELLCHECK CANCEL] 



[-INTERACTIVE HELP PANEL — i 



FIG. 14 



E-MAILCOP 



FILE ADDRESS BOOK ACCOUNT BOOK HELP 





CREATE 


SEND 


RETRIEVE 
MESSAGES 



□ ENCRYPT 

□ SIGN 

□ COMPRESS 



OACCOUNTBOOK 
O ADDRESS BOOK 
O MESSAGE BOOK 



SIGNATURE FILE- 



EDIT YOUR SIGNATURE FILE IN THE , 

TEXT AREA PROVIDED ABOVE.TOSA/E CREATE SIGNATURE 

YOUR CHANGES t SELECT TH E CREATE 1 

SIGNATURE BUTTON.TO EXIT AND ^ENABLE APPENDING 
RETURN TO THE PREVIOUS SCREEN, 
SELECT THE "DONE^UTTON 



DONE 



[-INTERACTIVE HELP PANEL — i 



01/05/2004, EAST Version: 1.4.1 



US 6,3i 

1 

INTEROPERABLE FULL-FEATURED WEB- 
BASED AND CLIENT-SIDE E-MAIL SYSTEM 

FIELD OF THE INVENTION 

The present invention relates to systems and methods for 
providing electronic messages and other communications 
using the Internet or World Wide Web ("Web") and a variety 
of personal and other computers available to different sub- 
scribers and users. 

BACKGROUND OF THE ART 

Most all persons that are engaged in commerce and/or in 
any sort of interpersonal relations are, by 1999, very well 
familiar with "e-mail" as a form of virtually-instant, written 
communication using the Internet and the World Wide Web. 
Many millions of people in the US and abroad now have 
access to computers they may use at home, at work, at 
school (from grade -school to college), at public libraries, at 
"cyber-cafes", at office services centers or stores, at col- 
leagues' offices and homes, and at myriad other places. On 
such computers they can compose and send or receive 
e-mail messages using a modem, an Internet Service Pro- 
vider ("ISP"), and an e-mail program either loaded into the 
computer or provided, often free, by the ISP or another Web 
host. Eudora® is a commercial e-mail program loaded onto 
a user's computer (i.e., "client-side") for composing and 
sending and receiving e-mail. Client-side programs are often 
required for use at colleges, allowing students to work 
off-line and. then dial in to the central server just to upload 
and download their messages. Hotmail® and many other 
e-mail systems reside on servers accessed form the Internet, 
such as those at msn.com, and can be accessed only while 
on-line with the e-mail system server via the Internet. 
However, a user must be at his or her own computer to use 
the client-side application, and has no access to such e-mail 
otherwise, as while travelling without the computer. Further, 
a user relying on Web-based e-mail can work on the e-mail 
system from any computer with an Internet connection, but 
only while connected to the Internet and incurring telephone 
and other charges. 

No commercial e-mail service is known to provide both 
on-line and client-side services that are similar to one 
another in use. A need exists for a subscriber to be able to 
work selectively either (1) from his or her own computer 
using personal settings, information, and files, or alterna- 
tively and equally well, (2) from any other computer through 
a server that can access the user's "home" server and still 
have available the user's personal settings, information, and 
files. 

Security is also a need for electronic messaging. Mes- 
sages and attachments are typically sent between computers 
and servers and between servers over non -secure lines, and 
stored on intermediate servers as they are routed to their 
destinations. Messages are sent in multiple "packets", so that 
not all of a message will go the same route to its destination 
server, thus providing some inherent security in the Internet 
system. However, messages and attachments stored on the 
origin and destination servers are vulnerable to snooping by 
persons with knowledge of computer intrusion tactics. 
Encryption techniques are known, whereby a subscriber 
may encrypt his or her text before it goes to the origin server 
and the text stays encrypted until it reaches the recipient's 
computer, where it is displayed as plain text without further 
action by the user. Complete security systems for electronic 
messaging require also, however, additional features of 
authentication of the sender's identity, integrity of the mes- 
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sage and attachments as against modifications in transit, and 
assurance against repudiation by the sender. None of these 
three added security features is available on any known 
Web-based e-mail system, although some client-side sys- 

5 terns provide them. 

Many security standards and algorithms are available for 
use in secure messaging. S/MIME, SSL, and X.509 stan- 
dards are used in some secure client-side systems but not in 
any known Web-based system, except that SSL (Secure 

20 Socket Layer) is used in two recently released commercial 
products, noted below. Many security algorithms are known 
and used in secure client-side e-mail systems, including 
3-DES, Diffie-Hellman, DSS, MD5, RC2/40, RSA, and 
SHA-1; none of these is used in any Web-based application, 

15 save one of the recent commercial products. That product 
uses Diffie-Hellman and a further algorithm called Blowfish. 

Useful e-mail systems provide additional features, besides 
simple messaging, that are helpful and desirable. Permitting 
address book(s), attachments, downloading of messages, 

20 and filing of messages into separate folders are typically 
allowed on some Web-based and most client-side systems. 
Features of checking multiple e-mail accounts and affording 
universal access from any computer are provided by Web- 
based systems but not by client-side systems. Typically, 

25 when users want help on a particular subject or action, they 
must obtain assistance from a menu or sub -menu, then 
search the help listing for the appropriate subject. Often, 
these help menus are inadequate or confusing or don't even 
try to offer the information the user requires. Virus warnings 

30 and dual naming procedures for log-in are known but not 
commonly used. 

Very recently, two secure, Web-based e-mail systems have 
appeared commercially, under names of ZipLip and Hush- 

35 Mail. Both of these systems provide concealment or privacy 
features, but neither includes the three other data security 
features of authentication, integrity, and non-repudiation. 
They use Secure Socket Layer (SSL) security standards for 
encrypting messages in transit. HushMail uses the Diffie- 

40 Hellman algorithm (which is recognized in the S/MIME 
standard) as well as the Blowfish algorithm (which is not); 
ZipLip uses none. Neither system permits message down- 
load or multiple e-mail account checking, but both permit 
universal access from any computer with Internet access. 

45 ZipLip permits attachments, while HushMail does not. 
HushMail has address book and message folder features not 
in ZipLip, and ZipLip permits attachments whereas Hush- 
Mail does not. Neither system is interoperable with other 
systems, but one must use the ZipLip or the HushMail 

50 systems to access messages developed within those systems. 
Microsoft has recently offered a Web-based tool referred 
to as Outlook Web Access ("OWA"), as a part of the 
Microsoft Exchange server. Included already in Microsoft 
Exchange has been "Outlook Client" ("OC"), a full- 

55 featured, client-side e-mail software application, which sup- 
ports the S/MIME standard. The OWA program permits a 
subscriber to access his or her messages residing on an OC 
server for sending or receiving same from over the web, but 
there is no access while on OWA to a subscriber's personal 

60 information, files, or settings. OWA is not S/MIME 
compatible, so the client-side and Web-based capabilities 
and experiences are very different. 

Thus, no known e-mail system or service, Web-based or 
client-side, offers features of compression of attachments on 

65 demand, an integrated certificate authority and service 
provider, both Web-based and client-side access, an inter- 
active help system, a virus warning system, and dual-naming 
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log-ins, built into the system. Rather, such features and 
functions must be accessed and accomplished if possible by 
going to other programs, slowing a user's electronic mes- 
saging procedure greatly. 

SUMMARY OF THE INVENTION 

The present invention provides a robust, full-featured 
electronic messaging system with combined Web-based and 
client-side access that works equally well both from a 
subscriber's own computer with proprietary software or 
from any other computer connected to the Internet, with only 
very small differences in appearance and operation. Either 
way of access allows use of all features of the invention, 
including all security features noted below if the Internet 
connection is suitable. 

The present invention provides both a basic form of 
service, both Web-based and client-side, and also a 
premium, secure level of service with all four of the security 
features of authentication, concealment, integrity, and non- 
repudiation, when used from the subscriber's computer or 
with a suitable Internet access. 

The present invention permits inter-exchange of elec- 
tronic messages with others that are not subscribers to the 
present system. For a subscriber to send a secure message to 
a person not a subscriber, the user need only be sure that the 
user's server and computer are set up to use the S/MIME 
protocol. 

The present invention provides additional important fea- 
tures of multiple account checking, universal access, attach- 
ment compression on demand and automatic 
decompression, integrated certificate authority and e-mail 
service, interactive help, a uniform hierarchy for books of 
messages, e-mail accounts, and certificates, a virus warning 
system, and dual-naming log-in protections. All are useable 
from the subscriber's own computer, using the software 
system of the invention, and alternatively from any com- 
puter with suitable Internet access, using a password or 
-phrase to access the subscriber's own information, files, and 
setup. 

The method of the present invention provides for pro- 
gramming both a Web-based server and a personal computer 
application with an e-mail messaging service configured to 
interact with and to shadow each other as to personal 
information, settings, and files of an individual one of said 
subscribers. The method includes steps of storing the per- 
sonal information, settings, and files of a subscriber both on 
the Web-based server and on a personal computer running 
the application. Then the subscriber may access his or her 
files off-line solely through the personal computer and may 
alternatively access the files on-line through any computer 
able to communicate with the server. Access is then allowed 
to the messaging service via the server for a subscriber's 
sending and receiving electronic messages. 

The present invention further provides for a digital cer- 
tificate service with the messaging service. The Web-based 
form of messaging service is made secure against intercep- 
tion of messages. A subscriber can access the server of the 
messaging service from a personal computer using the 
Web-based form of service through an S/MIME compliant 
application to connect between the computer and the server. 
In a Web-based environment, a digital signature is provided 
to an authorized recipient, the signature verifying the iden- 
tity of the sender, the integrity of the message, and the fact 
of the sending by the sender. The user is given control over 
whether or not to compress the file size of each outgoing 
attachment to a message; for subscribers, the decompression 
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of each compressed attachment happens automatically when 
a subscriber opens it. Interactive help screens are provided 
on each subscriber's computer, both on-line through any 
computer and off-line if used through the subscriber's com- 

5 puter. Each of these help screens is displayed as it becomes 
pertinent to the task being then executed by the subscriber. 
The subscriber may turn any of these help screens on and off, 
however. A substantially uniform book hierarchy is provided 
for messages received and messages sent, e-mail accounts, 

io and certificates available to the subscriber. A warning of 
possible virus contamination of attachments to a message is 
provided. Dual naming capability is available in the inven- 
tion for more secure log-in, by requiring a log-in name as 
well as a user name upon log-in. 

15 

BRIEF DESCRIPTION OF THE DRAWINGS 

FIG. 1 is a general operating diagram of the method of the 
present invention, depicting operation of the electronic mes- 
20 saging system in different circumstances for various sub- 
scribers and users. 

FIG. 2 is a detailed depiction of the architecture of the 
system, showing functional servers and connections. 

FIG. 3 is a depiction of the chain of certificates used in the 
25 system for verifying identity of the senders of messages in 
the system. 

FIG. 4 is a depiction of the security system used in the 
invention for communications lines. 

30 FIGS. 5 through 14 are screen shots of the various screens 
used in a preferred embodiment, implementing the inven- 
tion. 

THE PREFERRED EMBODIMENTS 

35 

The present invention combines network/server architec- 
ture and, in one embodiment, a privacy-enabled e-mail 
application. This application, here called "EMC" for short, 
allows any e-mail service provider to offer privacy-enhanced 
40 e-mail to its users. EMC was developed with the following 
goals in mind: 

1. The architecture must be robust and scalable in terms 
of cost and security, 

2. The architecture must provide a standard level of 
45 security in any configuration, 

3. The architecture must provide an overall security 
package to the client and the end-user, 

4. The e-mail application must be universally applicable, 
5Q to fill any user's needs, 

5. The e-mail application should incorporate many useful 
features that are not found in currently existing e-mail 
applications, and 

6. The e-mail application should be easy to learn and use, 
55 and should provide continuous feedback to the user. 

The architecture of the invention has a minimum set of 
requirements that allow ISP's the opportunity to implement 
EMC with little or no additional overhead costs. This 
minimum set of requirements can be utilized to provide a 

60 robust platform from which to provide secure e-mail ser- 
vices. EMC attains goals nos. 1 and 2 above through the 
hardware/software specification of the EMC network. This 
network is scalable in terms of the number of servers used, 
the type of connections used between servers, and the 

65 backup capability of the servers. This underlying architec- 
ture uses state-of-the-art technology to provide the means by 
which EMC fulfills goals nos. 3-6 of the previous list. 
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The architecture of EMC was designed for three purposes: 1. Fully integrated, controllable compression/ 

1. To securely provide certificates to end-users, decompression; 

2. To securely provide a Certificate Repository, and 2. The Web-based form is capable of using privacy 

3. To securely provide the mail server for the e-mail enhancements as provided by X,509 certificates; 
applications specified for use with EMC. 5 3. A context-sensitive Interactive Help Panel for interfac- 

These three purposes are met by the architecture ing continuously with the subscriber as the program is 

specification, which provides these services securely by used; and 

strategically using firewalls, secure routers, public key 4. A "Book" system as is typically applied to e-mail 

encryption, and specific authentication protocols. This address organization in other e-mail applications is 

design offers an overall security package for the service 10 extended to organize message lists, account lists, and 

provider and the end-user. Fulfillment of these goals is certificates. 

achieved through implementation of the e-mail application Several of the above features merit discussion. First, most 
as in the implementation and system deployment example of e-mail applications (Web-based or client-based) do not 
FIG. 2. provide the end user with optionally useable compression/ 
As shown in the system architecture diagram of FIG. 2, a 15 decompression tools. Rather, the user must manipulate the 
subscriber to EMC will use a Web browser of recent vintage file to be compressed/decompressed in an application sepa- 
in conjunction with Java and other applications on his/her rate from the e-mail. A few e-mail applications automatically 
own computer, whether a desk-top PC, a laptop PC, an compress outgoing message attachments that are of a par- 
Apple machine, a workstation, etc. The application, in any ticular size and/or quantity, but the feature cannot be turned 
of various forms available, contains all the functionality of 20 off or varied. The present invention integrates compression 
the client-side EMC program, loaded to the hard drive of the technology and places control with the end user or sub- 
subscriber's computer as from a CD-ROM or down-loaded scriber. 

and saved for execution from the Internet. The mail server The privacy-enhanced Web-based e-mail feature, at a 

and the Web/Application server cooperate at the server level premium level of service above a basic level, should provide 

through Servlets as shown to provide the functionality 25 all four of the important attributes of security: concealment 

needed at the server level, and to cooperate with the sub- of the message contents against snooping by others, integrity 

scriber through the browser as controlled through the EMC of the message as against changes in what the sender sent, 

application, as embodied in Java or a similar language. The authentication that the person or user named actually did 

Application and the e-mail server cooperate with a Certifi- send the message, and non-repudiatability by the sender that 

cate Authority to generate a certificate for communications 30 the message was indeed his or hers, 

and to keep that certificate for use when needed by the The program warns when messages or their attachments 

application either at the computer or the server level. Com- may contain viruses, worms, and other undesired programs 

munications among the different entities are conducted over that may harm the computer or its files. The user can then 

lines secured by the various protocols shown, or others of take appropriate action, including scanning with a detection 

similar effect. 35 program to confirm the presence and type of virus present, 

In order to create universal appeal, the e-mail application and to destroy the virus identified, by then taking appropriate 

provides two implementation forms and two levels of ser- further steps. 

vice. The first form is a Web -based implementation that uses The program further permits increased security by adding 

distributed computing technology to provide e-mail service a further layer of name protection. Currently, the user name 

without downloading by the end user. The second imple- 40 and log-in name are the same, although they need not be. 

mentation form is an application that is loaded on or EMC is set up to require separate entry of the user name, 

downloaded to the subscriber's personal machine and run log-in name, and password. 

locally. The ability to offer the two complimentary forms for The Interactive Help Panel of the invention extends the 

implementation is paramount to EMC's goal of providing known concept of such computer aids. The Interactive Help 

robust e-mail services. The Web-based form permits sub- 45 Panel continuously displays to the user suggestions and 

scribers who do not have their own computer, who travel, or "tips** for the current action the user is performing. Thus, the 

who otherwise use different computers to access and use Interactive Help Panel is context sensitive, i.e., it "knows** 

these e-mail services. The client-side application is used by where the user is in the program and what the user is trying 

subscribers who do not want to be online for long periods for to accomplish, and it continuously offers instruction on how 

composing and reading messages. The ability of a single 50 to complete the task. 

subscriber to use either of these implementations The invention offers a "book based organization" that is 

alternatively, on the same account, provides universal access modeled upon the conventional address book. Received/ 

to versatile e-mail services. draft messages, user accounts, and digital certificates are, 

The Web-based form of the invention uses distributed according to the invention, organized as separate "books." 

computing technology to provide full-featured e-mail ser- 55 Thus, EMC provides an Address Book, Account Book, 

vices to an end -user subscriber from any suitable computer Certificate Book, and a Message Book, This innovation 

that is connected to the Internet and has an Internet browser. provides the subscriber with a familiar way of viewing 

Currently, full-featured e-mail with privacy enhancements is different information. 

available only in those e-mail applications that are run on the Cryptography is the process of hiding information; that is, 

end-user's local machine. The drawback of this approach is 60 when something is encrypted it is rendered unreadable to all 

that the user needs to be at that machine in order to use the but certain people who are able to see the underlying 

e-mail application, and thus have all the expected e-mail information. Two types of encryption are used today: public 

features and also secure communications. The Web-based key and private key. Private key cryptography requires two 

form of this invention provides secure communication to or users to share a secret key (i.e., only they know what the key 

from any place the subscriber is located. 65 is) and makes use of this common knowledge to hide 

The two forms of the invention have the following correspondence and other data from would-be eavesdrop- 

features that are unique to EMC's architecture: pers. Public key cryptography provides each user with two 
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keys. One key is publicly available, and the other is kept broken by brute force. However, 3-DES has not yet been 

privately (i.e., no one else knows the key's value). In public broken. The most common public key cryptosystem is the 

key cryptography, concealment is achieved when one user Rivest, Shamir, and Adleman algorithm ("RSA"). It has not 

encrypts a message using the intended recipient's public key. yet been broken, and is as strong as its key length (similar 

The recipient can then use his or her private key to decrypt 5 to DES in this respect). 

the message. No person can decrypt the message except the A somewhat less powerful public key cryptosystem, pres- 

user who possesses the private key that corresponds to the ently useful for export purposes, is RC2/40, by the devel- 

public key with which the message was encrypted. opers of RSA. It works with a 40-bit key, and is not 

Client-side e-mail messaging systems may use both pub- considered secure. However, it can be exported without 

lie and private key encryption to conceal messages. This is 10 consent from the US government because its key length is so 

primarily because public key encryption is much slower than short. 

private key encryption. As a result, a secret key is randomly Digital signatures are achieved by using a specific 

generated and used to encrypt the outgoing message. Then, algorithm, and always use public key cryptography as a 

the secret key is encrypted with the public key cryptosystem, foundation. The Digital Signature Standard ("DSS"), also 

and the encrypted message is sent with the encrypted key. 15 known as Digital Signature Algorithm ("DSA"), is specified 

By themselves, cryptosystems are inadequate in the sense in FIPS PUB 186-1. The DSA does not, however, sign the 

that anyone can encrypt a message to send to someone else entire message. Rather, a message digest or hash is first 

without proving their identity; that is, it would be easy to created using a particular algorithm. Message digests are 

forge an encrypted message to someone else. Requiring the formed in fixed lengths and derived from an arbitrary length 

use of digital signatures, below, combats this possibility. 20 message in such a fashion that no two unequal messages will 

A digital signature is a piece of information sent with a result in the same digest. DSA first computes the message 

message that proves that the message originated from a digest of the message it wishes to sign, then encrypts the 

particular person. It is analogous to a written signature, and resulting hash value with the private key to create the 

is, in some situations, considered to be legally binding, signature. This signature is then appended to the message 

Digital signatures serve for non -repudiation as well as 25 and sent as usual. 

verification functions. Two message digest algorithms are important here. The 

The use of digital signatures and public key cryptography first is MD5, developed by Ron Rivest (of RSA fame). MD5 

is powerful; however, it does have its flaws. If used without produces a digest quickly, but not necessarily very securely, 

the proper structure, there is no way to identify the indi- as it has some known weaknesses. The second, and more 

vidual sending a message. In fact, anyone could sign and 30 important, hashing algorithm is the Secure Hash Algorithm 

encrypt a message without ever revealing his or her identity. ("SHA"). SHA is specified in FIPS Publication no. 180-1, 

A digital certificate enables an individual sending a message and has no known weaknesses. SHA takes slightly longer to 

to prove his/her identity, at least partially. A digital certificate process information than MD5; however, the trade-off 

contains a user's public information and a signature from a between time and security is well worth the wait, 

certificate authority (e.g., VeriSign, Inc.). Digital certificates 35 Furthermore, SHA is specified to work with DSA and the 

and their use are standardized in the X.509 standard. When forthcoming ECDSA, below. 

digital certificates are used, there is little question of validity, The state-of-the-art of digital signatures and cryptography 

non-repudiatability, and integrity of sent messages. relies upon elliptic curve cryptography ("ECC"), a public 

In sum, there are four basic security issues in electronic key cryptosystem. ECC offers greater security at a substan- 

communications: concealment, integrity, authentication, and 40 tially lower key length than RSA or other public key 

non-repudiation. The solution to these problems is referred cryptosystems. There are currently two identical draft stan- 

to as full digital security. The application of cryptography in dards (IEEE P1363[12] and ANSI X9.62[l]) that define the 

its various forms addresses each of these concerns; however, DSA for elliptic curves (ECDSA). Elliptic curve 

the application must be appropriate for these concerns to be cryptography, given its strength-to -key-length-ratio, is the 

properly addressed. Digital signatures, if used properly, 45 future of cryptography, and existing standards, such as the 

provide non-repudiation, authentication, and data integrity. X.509 certificate standard, will aspire to accommodate vari- 

Encrypting an entire message provides concealment. By ous ECC algorithms in the future. 

using encryption and digital signatures properly, one can As an additional note, the National Institute of Standards 

achieve a secure communication foundation with the only and Technology ("NIST") is seeking a replacement for DES. 

potential risk, besides the compromise of privately guarded 50 This replacement will be selected from a pool of 15 candi- 

information, e.g., private keys, being brute force attacks, but date algorithms currently under review. The replacement is 

this depends largely upon the cryptosystem being used. already known as the Advanced Encryption Standard 

Several cryptographic algorithms are widely used today. ("AES"). AES is expected to be finalized early in the year 

The most common private key cryptosystem is the Federal 2000. 

Government's Data Encryption Standard ("DES") as speci- 55 The Secure Multipurpose Internet Mail Extension ("S/ 

fled in Federal Information Processing Standards Publica- MIME") protocol provides a secure overlay for the Internet 

tion ("FIPS PUB") 96. DES is a private key cryptosystem, mail standard MIME. MIME is an Internet standard docu- 

which means that any two parties wishing to communicate mented in RFC's 2045-2049, providing extensions to the 

securely must share a common key. The data to be concealed basic e-mail standard RFC 822. These extensions provide 

is encrypted with this key, sent, and then decrypted with the 60 for greater flexibility and interoperability of existing e-mail 

same key. A variant of this standard is referred to as applications as well as expanding the type of data that can 

triple-DES or "3-DES". 3-DES typically uses two keys and be sent via e-mail. Secure MIME provides the capability to 

three rounds in the following manner: first, the message is use certificates and a variety of cryptosystems. Currently, 

encrypted with the first key, then the result of the first round S/MIME supports the following cryptographic mechanisms: 
is decrypted with the second key, and, finally, the result of 65 SHA-1, MD5, DSS, RSA, Diflie-Hellman, 3-DES, RC2/40. 

the second round is encrypted with the first key. DES, which These cryptographic algorithms comprise a good set of 

is specified to have a key length of 56-bits, has recently been cryptographic tools. 
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S/MIME provides a universal cryptography tool kit with Each local network using a Kerberos authentication sys- 
which a user can enhance the privacy of e-mail correspon- tem can be scaled with other networks implementing Ker- 
dence. S/MIME is specified for using the X.509 v3 certifi- beros. Each network is called a realm, and the multiple 
cate standard, and uses this standard as a basis for forming networks implementing Kerberos are referred to as Kerberi. 
trust among individuals. A centralized authority issues these 5 That each realm can interoperate with the other is useful for 
certificates, thus providing a verifiable path of trust. lhe obvious reason that several smaller, modularized net- 
Central to many Internet services is the issue of user works can communicate securely, 
authentication. Authentication here refers to the ability to There are currently two versions Q f Kerberos in use, and 
determine that a sender is who he/she claims to be, in that m afe ti for wider accep tance. These versions are 
the sender is bound to the name used. A subtle distinction „ v . * j t7 u c \r c ■ ui 
, t ... . c « i - 10 Kerberos v4 and Kerberos v5. Version 5 is a major overhaul 
exists between this definition and other uses of c . , 4 4 , . . A . iL i e ~ 
"authentication", which may rather require proof that a of v4 > £?. objectives are the same. Version 5 offers 
user's identity is not false. Here, authentication only binds a greater flexibility as to the environments m which it can be 
single, unique user to the user name. That is, the user name a PP lied b y enabling Tickets with more extensions than those 
relates to a particular person, who may remain anonymous. in version 4 - EMC 18 specified to use Kerberos v5. 
To authenticate the identity of an individual to whom a 15 Certificates adhering to the X.509 standard are those that 
username belongs requires physical presence of that indi- are issued by a granting authority for use in secure e-mail 
vidua!. and digital signatures. The X.509 standard has several 
For a subscriber to log-on to EMC, a separate (i.e., different versions, the latest of which is version 3. Version 3 
non-certificate-based) authentication procedure is used, contains extensions that are not found in the previous 
employing public key cryptography in accordance with FIPS 20 versions and allows for greater messaging flexibility. Aside 
PUB 196, ("Entity Authentication Using Public Key from defining the specific content of certificates, the X.509 
Cryptography"). Once the user is logged into the service, all standard also sets the stage for Certificate Authorities and 
requests are performed with Kerberos wrapped in IPSec how they are to implement the use and issuance of certifi- 
protocol. cates. More precisely, X.509 specifies that an issuing author- 
Kerberos is an authentication protocol that can be utilized 25 ity must create a Certification Practice Statement, which 
by subscribers and other entities requesting services on a defines various policies pertaining to the issuance and use of 
network. It is said to be scalable, but for the purposes of ^ <jqq cer tiflcates 

EMC, it needn't extend past a simple protocol level. Ker- 'unfortunately, the above practice allows for wide policy 

beros uses public key crypto^aphy to authenticate users variaQce betweeQ differeQt issui authorities . However> al 

wth an y^emication Server ("AS ), and a Ticket Granting 3Q ^ tWQ &Qups afe CUfrently WQrkiog Qn extending the 

Server ( TGS ) J . L f r „ . . , X.509 standard to close some of the "holes" that are left to 

Kerberos was designed with the following implements be m ^ ^ {Q proyide for a bettCf standard , n particulaf 

tion goals: the Key Informatiori Exchange ("PKIX") is a work- 

1. Secure: An eavesdropper should not be able to obtain ing draft of the Intemet En gi ne ering Task Force and will be 
any information that would allow impersonation. Ker- 35 a sup e rS et of X.509. Another group, the Meta Certificate 
beros should not be a weak link in the security chain. Group> fa also ^ c]dn$ t0 expand on the x 509 standard . 

2. Reliable: Kerberos should be implemented with redun- when the working drafts are implemented as standards, 
dancy in mind, to prevent denial of service attacks. those entities employing X.509 certificates will easily tran- 

3. Transparent: Ideally, the user/entity being authenticated sition to the new standard of choice. 

should not be aware that authentication is taking place, 40 FIG. 3 represents a certificate chain that validates various 

with the exception of a necessary user password. certificates. The notation X«Y» is defined in the X.509 

4. Scalable: Kerberos was designed for a distributed, standard, and is read as X signs Y. The root must be a 
modularized world. Certificate Authority. There can be many trees with many 

Thus, the model is scalable to numerous clients and roots in existence and they will all be able to certify each 

servers. 45 other, provided that each root has signed the root of the other 

This authentication scheme is typically used for user trees. That is to say that if two trees, say A and B, have 

authentication, but is suitable for entity authentication as distinct certificate chains and the CA(root) of each tree has 

well. An entity is defined to be a process or server that signed the other CA's root certificate, any certificate on 

requests service from another process or server. either tree (A or B) can be verified by any other certificate 

A Ticket is similar to a certificate and contains informa- 50 on either tree (A or B). 

tion about the entity making the request and the nature of the A Certificate Authority ("CA") provides a trustworthy 

request. Kerberos is designed to virtually eliminate any certificate chain to users of the Internet. Certificates typically 

compromise of passwords and private keys, replay attacks, conform to X.509 standards. Furthermore, CA's are 

and other potential security risks. This does not mean, required, as stated in X.509, to create a Certification Practice 

however, that Kerberos is flawless. Kerberos relies upon 55 Statement ("CPS"). The CPS is what defines a CA and its 

time synchronization between servers. If an attacker could offerings, VeriSign, a PKI corporation that provides three 

somehow fool a server into believing the time was different levels of certification in a class system, provides the best 

than it was supposed to be, then the attacker could circum- example of a CA. The three certificate levels that VeriSign 

vent Kerberos. No authentication protocol is completely offers are class 1, class 2, and class 3. Class One certificates 

flawless. 60 have the lowest secure authentication, and Class Three 

On a basic level, the entity requesting a service sends a certificates have the highest level, 
request to the authentication server, which replies with an A CA should have differing levels of certificates; 
encrypted Ticket. The Ticket is decrypted by the entity however, a three-tier class structure seems to be too con- 
applying for services, and then sent to the TGS. The TGS fusing and complicated for EMCs purposes. Certificates 
then replies with a Ticket for the particular service requested 65 provide for secure e-mail and non-repudiation: however, the 
and that Ticket is sent to the server from which services are true identity of the user on the other side of the communi- 
requested. cation is still unknown. Thus a two-tier class system should 
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be all that is necessary. The lowest level of security a e-mail address or password, whereas the higher level of 

certificate should offer is that which binds an e-mail address verification binds the certificate, the e-mail address, and the 

and a credit card account to the user applying for a certifi- actual identity of the individual. This is not necessarily 

cate. There is no guarantee that no credit card fraud is taking foolproof, as an applicant presenting false identification to 

place, thus identity is not absolutely proven. 5 the notary public or other officer could circumvent even the 

The second, and higher, class of certificate guarantees highest level of verification, 

authentication of the user's true identity via physical iden- The EMC hardware architecture provides secure e-mail 

tification. This means that the user applying for a level-two services from a safe, yet flexible source. Consideration is 

certificate needs to be identified with proper credentials (i.e., given to security, authentication, validation, and ease of use. 

a passport or driver's license) by the CA or a licensed 10 The Architecture may consist of several servers: mail, cer- 

signatory. A particularly easy method of achieving this goal tificate authority, web/application, and a servlet server (as 

would be to have the user download and print a legally shown in drawing FIG. 2). All servers communicate with 

binding document (the document can contain a digital Kerberos authentication wrapped in IPSec protocol, as in 

watermark to protect the integrity of the document) that the FIG. 4. 

user can sign in the presence of a notary public or other is Secure communication between servers is accomplished 

official. The document is then physically sent (by courier or by using IPSec, an Internet security protocol applicable to 

mail) to the issuing CA for confirmation. The approved local area networks. IP Security specification is complex, but 

applicant would receive the issued certificate in one of two is well documented in the following RFC standards released 

ways. The certificate would either be distributed via pass- by the Internet Engineering Task Force: 

word authenticated secure Web download, or it could be sent 20 RFC 1825: An overview of a security architecture; 

via certified mail or by some other trusted courier. RFC 1826: Description of a packet authentication exten- 

A Certificate Authority has several issues with which to be s j on l0 jp. 

concerned First is the concern over the secure delivery of RFC lg27 . ^ tjor) of a kel encryption exlension 

private information oyer the Internet. This pertains to the jp. 

distribution of approved certificates of any security class, A 25 „™ „ ' . . 

secure connection, either via a new dial-up number or via a 1828: s P ecific authentication mechanism; and 

secure Web page using SSL, must be established and appro- RFC 1829: A s P ecific encryption mechanism, 

priately used to distribute a new certificate. Second is the T^ specification for IPSec is known to those of skill in 

concern over the validity of the claim of identity made by an the art ' D^rences exist between communications between 

applicant. In other words, is the applicant really who he/she 30 servers and communications between a server or ISP and a 

claims to be? Unfortunately, without physical appearance user - The communication between the server and the user 

and credential checks, there is currently no cost-effective («-S- sending e-mail) is handled by Kerberos, and the 

method to achieve valid authentication of identity by digital- underlying communication between servers is handled with 

only means. Third is the plausible lifetime of a certificate. IPSec. See FIG. 4. 

By some mathematical models, the lifetime of a root cer- 35 ^ securit y redundancy helps eliminate "sniffers" and 
tificate should only be about two weeks. By practice other would-be attackers from snooping on communica- 
standards, however, the root certificate lasts for a year or tions - Furthermore, Kerberos virtually eliminates replay 
longer attacks, regardless of the underlying communication secu- 
The architecture of the present invention relies on each ritv - Perha P s the best wav t0 understand the way different 
operator of the system (e.g., each ISP) being either an 40 lev els of security are engineered is to think of requests for 
Issuing Authority (granted a license by the ultimate CA), or service as bein § Kerberos, and communication of those 
being the CA itself. The Certification Practice Statement requests as being handled by IPSec. 
("CSP") of EMC's architecture requires that varying levels The EMC servers are functionally different from one 
of true authentication be provided in a two-tier system, and another > thus each server nas dlfferent operating require- 
that key generation, root certificate generation, and destruc- 45 me ats. The optimal operational requirements, as presently 
tion of keys and root certificates be done on a FIPS 140-1 known > for the w™** are ^ ted bclow Wlth brief justifica- 
level four approved computer. Moreover, the CPS provides tions - These requirements are necessary to meet EMC's 
requirements for setting up the certificate service when most secure specifications: 

implementing the EMC architecture. That is, when autho- TGS: this server should be a dual processor (quad 

rization is licensed to any issuing authority, the authority 50 capable) system running a B2 trusted operating system, 

must provide proof that the architecture of EMC is in This & the server that S rants Tickets to requesting 

conformance to security guidelines as specified in the archi- entities. High processing speed is a requirement in that 

tecture layout and in the CPS. These requirements provide lnis server is often asked to do a lot of work in a short 

for cohesion among those issuing authorities affiliated with amount of time. 

the certificate authority. 55 AS: this server also should be a dual processor system 

Essentially, the CPS is the central controlling point for running a B2 trusted operating system. The authenti- 

EMC and is the doctrine by which EMC is implemented. cation server need only be applied to once per session 

The familiar VeriSign Certification Practice Statement pro- when using Kerberos v5, thus the server must be at 

vides an adequate foundation from which extensions can be least as fast as the TGS, and the TGS must be at least 

made to provide a more comprehensive, authentication- 60 as fast as the AS. The trusted operating system is 

friendly service. EMC provides two "levels" of confidence necessary because this server provides entity authenti- 

when generating its certificates. The lower level of confi- cation. 

dence verifies the user's identity via digital information, and PKS: this server should have dual processors, is qua- 

the higher level of confidence requires the user to sign a druple processor capable, and is highly expandable in 

legal document in the presence of a notary public or similar 65 the number of hard-drives it can accommodate. It is 

officer for personal identification verification. The lower important that this server be "hot swappable" so that 

level of verification only binds a certificate to a particular new hard-drives can be added without an interruption 
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of system service. Because this server houses the 
Certificate Revocation List, it, too, runs a B2 trusted 
operating system. 
Mail: the mail server should be a quadruple processor 
machine with hot swappable disk expansion. Much 
information is continually changing on the drives of 
this machine, thus the processing speed needs to be 
high. Of similar importance is the level of the operating 
system for the mail server. As with the other servers, 
this server also uses a B2 trusted operating system. The 
combination of speed, flexibility, and trustworthiness 
creates an environment that is conducive to good 
business. 

KCGS: this is the most critical server. This server must 
conform to level four security levels as specified in 
FIPS PUB 140-1. Furthermore, each of the two 
required machines should contain dual processors and 
be quad processor capable. There are periods when 
these machines are required to generate much math- 
ematical data in short amounts of time; thus the pro- 
cessor speed is of the utmost importance. Storage 
space, however, is not a large concern. Sufficient stor- 
age is necessary to store any cryptographic files that are 
necessary for generating digital certificates. 
Firewall: the firewall server is also of critical importance, 
whether there is a single firewall or a dual firewall 
configuration. The firewall is responsible for "filtering" 
incoming traffic as well as releasing outgoing traffic. As 
such, the firewall should be run on a quad processor 
machine. The firewall requires little in the way of 
hard-drive space, but a substantial amount of RAM. 
The firewall(s) conform to the B2 trusted system status. 
Public Access: the public access server should be a dual 
processor machine. This server is the central location 
from which individuals check publicly available infor- 
mation and/or apply for digital certificates. The amount 
of hard drive space required by this server depends 
largely upon the amount of information to be stored on 
it. Because the Public Access server acts as an access 
point to critical server processes, e.g. certificate 
generation, it must reside on a B2 trusted system. 
The above represents general requirements for the various 
servers to be provided in any given implementation of EMC. 
Each server should run on a B2 trusted operating system (as 
specified in the Department of Defense "Trusted Computer 
System Evaluation Criteria"). The amount of Random 
Access Memory ("RAM") is commensurate to the duties 
and processing needs of the particular server. Because some 
of the servers may be doing more or less work than others, 
the amount of RAM necessary varies between implementa- 
tions. Similarly, the amount of hard disk storage needed to 
be available to each machine must be determined for each 
system, individually. Some servers, such as the mail server 
and PKS, require substantial amounts of space depending on 
the number of clients the particular implementation will 
support. 

Where applicable, the server is highly expandable and/or 
extendable. As an example, the mail server will have the 
capability to expand as its user base grows. Once a mail 
server is at full capacity, another such server will need to be 
implemented, or a larger server will replace the existing one. 
In addition, each server must adhere to the requirements for 
server communication and entity authentication (IPSec and 
Kerberos). 

The EMC e-mail application is available in two forms: 
Web -based application and client -side. The basic function- 
ality of each implementation is the same. 
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The application is designed to operate as either an applet- 
like program that extends to the user's computer and is run 
through a Web browser, or as a downloadable application 
that runs exclusively on the user's machine. The application 
5 contains the following list of features to provide a compre- 
hensive and unique product. The following basic functions 
are found in both implementations: 
Users can receive mail from any existing POP3, I MAP, 
SMTP, etc. account; 
10 Vacation reply ability; 

Improved Address and Message Books; 
Spell checking capability of outgoing messages; 
HTML anchor linking (ability to invoke the default 
is browser); 

Multiple addresses, e.g., for various members of the 
family (secure communication with separate certifi- 
cates only); 
User definable appearance (e.g. wallpaper); 
The ability to mark read messages as "new" ; 
Read messages are automatically downloaded to the 
user's machine after a specified amount of time; and 
Print capability from the application. 
25 Each implementation requires different handling of func- 
tionality in order to emulate these features; however, the 
differences between the overall look and feel of each imple- 
mentation should go largely unnoticed by the subscriber. 
The e-mail application is designed to implement S/MIME 
30 messaging utilizing X.509 certificates. 

The cryptographic modules in EMC are of security level 
four quality as defined in FIPS PUB 140-1: 
"A Level 4 cryptographic module provides an envelope of 
protection around the cryptographic module. The intent 
35 of Level 4 protection is to detect a penetration of the 
device from any direction (rather than just attempts at 
the cover or door covered by Level 3 requirements) and 
respond by destroying critical information before it can 
be acquired. For example, if one attempts to cut 
40 through the cover of a cryptographic module, the 
attempt would be detected and all critical security 
parameters would be zeroed. Level 4 allows software 
cryptography in multi-user, multi-tasking systems 
when a B2 or equivalent trusted operating system is 
45 employed. A B2 operating system provides a large 
number of assurances of the correct operation of the 
security features of the operating system." 
Essentially, the cryptographic module containing the soft- 
ware that produces authentication keys, certificate 
50 information, root keys, etc., should reside on a level B2 
operating system. This makes reference to the Department of 
Defense Trusted Computer System Evaluation Criteria 
("TCSEC", or "The Orange Book"). In addition to providing 
extra detection, environmental controls must be placed on 
55 the module. That is, the module should be able to check 
environmental conditions (i.e., heat) and to zero essential 
information upon experiencing threatening conditions, e.g., 
too high a temperature, or the module should be rigorously 
tested against such conditions. 
60 The architecture of the EMC system provides security 
level four for the creation of digital certificates. This means 
that the machine, software, and any related hardware or 
software that is involved with the generation of keys, prime 
numbers, or any other portion integral to the creation of a 
65 digital certificate resides on a machine that meets the 
requirements to be certified for level four security as speci- 
fied in FIPS PUB 140-1. 
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The EMC architecture uses a rich array of cryptographic, The following outlines present the application features 

authentication, and other protection protocols. Most of these from the user's point of view. Each major feature is listed 

varying protocols have been standardized. These standards with its sub -features below, and is followed by a paragraph 

will undoubtedly evolve. Each standard chosen for its par- further explaining the features' intended purpose and their 

ticular duty promises to evolve nicely and evenly, thus 5 importance: 

providing EMC with a probable vertical evolution of its The Log-In functions: 

0W J1\ . ..... . . 0.1 User's Name 

This invention is designed to provide users with secure 

message transmission via the X.509 certificate standard as 0,2 ^S" 1 " Identlfic ation 

implemented with Secure Multipurpose Internet Mail Exten- 10 0-3 Password or Pass-phrase 

sions ("S/MIME"). The 3-step long-in requirement affords an added level of 

This invention has many distinct features and function- security for a user. Normally the User's name is used as the 

alities. The invention is designed so that an Internet browser Log-In identification, but this need not be so. 

can run one form of the e-mail service, or another form can The Send Messages functions: 

be loaded onto a user's local machine to be run as a standard 15 i.i Address Lookup 

application. Sufficient information is supplied in this speci- ^ ^ File Attachment 

fication to allow a developer to implement the invention. * _ „ ™_ , w ~ , 

TTie features are listed in a hierarchical fashion, thus 13 S P e11 Check Messa & e Bod y 

providing a developer the necessary background to suffi- 1-4 Compression Attachment(s) 

ciently modularize the implementation. The modularity pro- 20 1.5 Encrypt Message 

vides for easier coding and testing of the features contained 1.6 Digitally Sign Message 

in the application. The invention is described from the user's The user needs to have the ability to send messages. Sending 

point of view, thus providing invaluable insight for the messages involves composing a message, selecting an 

developer. If consideration is always given to the user, then address to which the message is to be sent, attaching media 

the final product will be a good one that users will enjoy and 25 flies, encrypting/signing the outgoing message, and, if 

appreciate using. applicable, compressing any of the attachments to the mes- 

This invention is an e-mail application consisting of many saget The composition feature is inherent to all e-mail 

common e-mail features, as well as some invaluable new applications. The application provides message composition 

ones. The major features of the e-mail application are listed w f m all of these features. 

De l° w: 30 The ability to compress outgoing message attachments 

Send and Receive messages, and Reply to and Forward from within the e-mail application is a unique feature of the 

messages application in that the compression is handled entirely by the 

Stop or initiate vacation response program application and relies on no external application. 

Inbox modification The Receive Messages functions: 

E-mail Account book modification 35 2.1 Add Address to Address Book 

Application appearance modification 2.2 Save Attachment(s) 

Enable or disable signature appendage 2 3 D e Compr ess Attachment(s) 

Address book modification ^ A \i -c rv n o- j 

2.4 Verify Digitally Signed Messages 

Message filters an „ _ _ 

, r • 2.5 Decrypt Messages 

Virus warning J r ° 

Dual naming 2 * 6 ' Virus Warmn S for Message Attachments 

These are the primary features that create the functional ^ receivin S messages, the application displays the infor- 

foundation for the e-mail application. These features are m / U u on ^portant^ m describing the message(s), the content 

further enhanced by adding the use of digital certificates 45 of ' he messa g e ^' and the size of the message(s). Tins 

(X.509 ), a built-in compression utility, and the overall dual ^formation is referred to as the header information of the 

functionality of being able to run through a browser or as a messa f ( s )- At first, only the header information is retrieved 

stand-alone application. frora the mai1 and dls P la y ed t0 ^ user. When the user 

This application is designed with two general environ- f Iect f a message to be read, then the complete message is 

ments in mind. Hie first environment is that of an Internet 50 downloaded and displayed to the user. Furthermore, attach- 

browser, such as Netscape Navigator. In this sense, the meDt are P r ™ ded P nor <° download. Some incom- 

application is to run through the browser in order to get to m & messa Sf be encrypted, digitally signed, and/or 

the user. The modular design of the application provides for compressed The application automatically performs 

simple transition between Web-based application usage and decryption, digital signature verification, and/or decompres- 

the second environment. 55 S1 °" necessar y- 

The environment first discussed is that of the Windows/ nt a PP"cation's ability to automatically handle corn- 
Intel environment pressed files is a unique feature. The application also decom- 

This section lists the features of the application in detail. P resse L s incomin g attachments that have been compressed 

The format is an outline that places each feature either as a Wlth > for instance » the g a P algorithm. 

top feature of the application, or as a sub-feature of another 60 rfhe View Message Book functions: 

feature. The highest features are those with the lowest 3.1 Add New Folder 

number. These initial features are described as "level zero", 3 2 Delete Existing Folder 

and each successive level of sub -features increments this a ^ ^ ~ d 1 

, , , c , j 1 r . . 3.3 Compose Reply Message 
count. As an example, level four would be a feature located 

five tiers "down" in the hierarchy. The feature listing can be 65 34 Mani P u l a ^ Message Status 

viewed as an upside-down tree where the root of the tree is 3.5 Order Messages in Particular Folder 

at the top. In this case, the root of the tree is the application. 3.6 Archive Folder(s) 
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3.7 Delete Message(s) 7.4 Item Placement 

3.8 Save Originator information 7.5 Delete Folder 
The application provides a rich set of tools that the user can 7.6 Delete Address 

employ to organize messages. The message folders are The address book is an important feature of any e-mail 

displayed to the user io a three-folder format. The three main 5 application. The application presents the user with a clean, 

folders are the inbox, the sent folder, and the draft folder. easy-to-use interface for creating, storing, and manipulating 

The inbox contains all messages received by the user, the e-mail addresses. Each address is treated as a business card, 

sent folder keeps a copy of all messages that the user has or data sheet, and contains the addressee's name, e-mail 

sent, and the draft folder contains those messages whose address, telephone number, fax number, house or business 

composition has been commenced but not yet completed. In 10 address, and notes about the addressee. Each of these 

addition to these primary folders, the user can add new address card fields are provided by the user, or taken from 

folders as sub- folders. Any created message folders can be a received message, i.e. an e-mail address. In addition to 

deleted and easily moved to a new location. This provides providing individual address organization, the application 

for organizational flexibility such that the user can create a provides the ability to create folders to hold addresses. The 

customized message folder hierarchy. " folders can be used in such a Way that they group those 

The Modify Account Book functions: addresses with something in common. For example, a par- 

4.1 Add E-mail Account ticular user may have several friends, business associates, 

4.2 Delete E-mail Account anc * f am ^y members with whom they correspond via e-mail. 

a i c„* tw,„,w r :i a„™,.,*/,a An address folder can be created for each category of 

4.3 Set Default E-mail Account(s) 20 , , r u r r • j r u r if ■ 

. zu correspondent — a folder for friends, a folder for business 

4.4 Get Messages from E-mail Account associates, and a folder for family members can be created. 

4.5 Create Account Folder The Modify Filters functions: 

4.6 Delete Account Folder 8.1 Create New Filter 
The user is given the opportunity to check all existing e-mail 8.2 Delete Existing Filter 
accounts through one server — the application's mail server. 25 g 3 Modify Existing Filter 
'ITie method in which it is presented to the user is unique. g 4 Q- ea t e Inbox Folder 

The user's accounts are organized in an account book. This ^ advanced feature of many e . mail applications local to the 

account book holds, m addition to account information, user > s machine is lhe ability to filter incoming messages, 

information that instructs the application if the user would Xhe user can create a fiUer that applies a mle t0 incoming 

like the accounts to be automatically checked, or manually messages . Messages that pass the tests set up by these rules 

checked. Thus, the user has complete control over what are theo placed int0 the desigoated folder cont ained in the 

e-mail accounts arc checked and when they are checked. The Inbox m a5ility t0 create message fllt ers requires the 

account book better organizes the various accounts a user abiHty l0 create folders in the Inbox direct]y from lhe flUer 

may have by providing the ability to group accounts into setup (in case the folder hasn > t akeady beeQ created) , 

folders, and to provide the user with a clean interface with ^ Vacation Reply functions* 

Wh j? w a ^ ss A other accou A nts - . 9.1 Enable Reply 

The Modify Appearance functions: r» ~ w JjC _ « 1 w 

3 rr 9.2 Modify Reply Message 

5.1 Alter Background Picture 9.3 Disable Reply 

5.2 Import Background Picture 40 "Vacation reply" is a feature that can be activated or deac- 
Many users have different tastes in music, entertainment, tivated as the user desires. A user can use the vacation reply 
food, and many other activities. Users of the Internet, and program on the mail server to respond to incoming messages 
thus e-mail, comprise the most diverse of all communities. wn il e the user is away. If the user is on vacation, or out of 
The application provides the user with the ability to set town f or a f ew daySj me user can enable the vacation reply 
visual preferences when using the application. Several back- 45 program from the application, tell the program what the 
grounds are available as well as poster cards, note cards, and reply is to bCj and then lurn it off when they return< ^ an 
other graphical designs. Furthermore, the user can import an advanced feature, EMC's reply program understands the 
image that he/she wishes to use. The application is com- concept of time, and can be preset to disable itself. Reply 
pletely customizable, giving users the feeling that they messages sent by the vacation reply program cannot be 
"own" the application. 50 signed or encrypted. 

The Modify Signature File functions: The Web-based and client-side implementations of the 

6.1 Enable Signature File application are inherently different. One runs on the Web, 

6.2 Disable Signature File ar »d tr >e other on the user's local machine. The differences 
6 3 Create Signature File between the states of operation arise primarily from the fact 
£. a \a i'f \2 ' »' o* c*i 55 tnat tne Web-based application has a different operating 
6.4 Modify LxKUng Signature bile environment th.n the downloaded applic.lioV. The 

Signature files are text files that are appended to the end of , , . . . . , .... . , r f , , , . 

j t*l c 1 c t * downloaded, client-side application simply downloads to the 

every message a user sends. These files are useful to users , , . , . r . . if 

. ■ . , j . 1 * . ■ r user s machine once, and is then run when the user wants to 

who wish to send a quote, place contact information, or . , \, 1 ™ , 

, , t , . e • A- generate or read his/her e-mail. The user connects to the 

include other information on every outgoing message. Sis- _f 4 . l l ,l . . i_ 1 c -i 

C1 , t j . « . °. . & 60 Internet when he/she wants to check for or read his/her mail 

nature files do not need to be used, thus the application 4 r™ . . . . i . , 

■j 1 L'i't 4 i_ i_ _ • f • at lhe server. This implementation can contain and process 

provides the ability to choose between using or not using a „ . f *. . , . , , . 

si nature file & & a ll necessary information completely on the local machine. 

w j**?' aj^ r» 1 cl On the other hand, the Web-based application cannot behave 

The Modify Address Book functions: ... . r , , .... rr , . jr 

. , . v T ^ , . tnts wa y because of bandwidth constraints and for other 

7.1 Add New Folder 6S reasons 

7.2 Compose to Highlighted Address/Folder implementation of the application (known as "client- 

7.3 Add Addresses) side") is run within a single frame (see FIG. 5). That is, when 
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the user launches the application, a single window appears, application is currently viewing a message, then the appli- 

and nearly all operations performed by the application take cation simply shuts down. If the application is in a running 

place within this window. The window contains a title bar, state, that is if it is currently performing some operation such 

menu bar, selection buttons, three radio buttons, three as encryption of an outgoing message, the ability to exit is 

checkboxes, three subwindows, and an Interactive-- Help 5 not available. This prevents the user from exiting during the 

Panel. The organization of the title and menu bars is familiar execution of a critical process. 

to users, in that the elements are located at the top of the The "get messages" option initiates the process of check- 
window and span the width of the window. ing for and receiving any new messages that are on the mail 
The selection buttons are "Create," "Send/' and "Retrieve server(s). If the application is currently performing another 
Messages" (FIG. 5). The Create button permits the user to 10 process, this option is not available to the user, 
compose an outgoing message. The Send button permits the The "create" option initiates the applications composer, 
user to send a message that has just been composed, and the The composer is fully described below. This option is 
Retrieve Messages button instructs the application to check unavailable when the application is performing another 
for new messages on the mail server(s). The three sub- operation. 

windows consist of a folder window, a larger, primary 15 The Compress | Decompress Folder option from the File 

window, and a medium-sized, viewer window. The folder menu places a dialog box in window three of the application, 

window is small and displays the various message folders as in FIG. 6. The dialog shows the status of the user's 

that the user has available. The larger window is a dynamic Message Book in a hierarchical fashion. The user can select 

window that may contain the composition of a message, a (highlight) a folder and then compress that folder. When the 

dialog with the user, or other functions. The medium-sized 20 message is compressed, it is saved in an alphanumeric 

window is for displaying message headers, account infor- fashion. As an example, if the Sent List were to be selected, 

mation (if in the e-mail account book), and address infor- the saved (compressed) file would be "sentl.cmp". The 

mation from the address book (if in the address book). folder would then be replaced with a new one. The new 

The three checkboxes provide the application with knowl- folder assumes the same name as the folder that was 

edge of the user's cryptography/compression preferences for 25 compressed. The dialog appears as shown in the image .of 

the current composition. The three radio buttons are used to FIG. 6. The user can delete as many folders as is desired or 

toggle among the address book, the account book, and the none at all. 

message book. From this dialog, the user may also decompress previ- 

The Interactive Help Panel at the lower right of the image ously compressed folders. A list of previously compressed 

is used to help guide the user through the use of the 30 folders is shown in the text box labeled "Archive List" in the 

application. The goal of the Interactive Help Panel is to give lower left-hand corner of the screen. To decompress a folder, 

the user information pertaining to the current state of the the user first highlights the archived folder from the Archive 

application without being "in the way" with extra windows List text box and then selects the "Decompress" button. 

. and/or unnecessary dialog boxes. The Interactive Help Panel When a file containing a folder is decompressed, the entire 

is described in detail below. 35 folder is placed within the current folder that replaced it 

The user interface is graphical and is organized as shown when it was compressed. If that folder has been deleted or 

in FIG. 5 and later figures. This interface was created using is otherwise not in existence, the application places the 

Visual Basic, although other languages can be used. The decompressed folder as a subfolder of the inbox. 

sub-windows are referred to, beginning with the top-most As an example, when the Draft List is archived and 

window and moving clockwise, as one, two, and three. Thus, 40 labeled as the file "draftl.cmp", where the "cmp" extension 

the third window is the largest window (where "Application represents a compression file, the application creates a new 

Logo placed here" is shown), the second window is the one Draft List to replace the old one. When draftl.cmp is 

just above the Interactive Help Panel, and the first window decompressed, a new folder is created in the Draft List 

has a vertical scroll bar. named "Draft List 1", and the messages/folder listings that 

The menu bar contains four menus: File, Address Book, 45 were contained in the compressed file is placed in this new 

Account Book, and Help. Each menu is explored below in folder. This option is not available if the application is 

some detail. currently running a process. To quit this operation, the user 

The Interactive Help Panel ("I HP') is displayed in the selects the "Done" button, which returns the application to 

lower right hand comer of the application window. The the previous state of operation. 

purpose of the IHP is to give the user useful tips, hints, and 50 The Preferences selection places a new display in the third 

suggestions when using the application. This panel is also window of the application (see FIG. 7). The preferences 

used for user prompting, especially when the user is about dialog allows the user to set certain defaults and to reinstate 

to perform a "destructive" act, such as modifying a message the Interactive Help Panel (if any of the options were 

filter, or deleting an address sheet. Each display of the IHP previously disabled). Default preferences are set upon instal- 

also includes a toggle switch that, when selected, will 55 lation of the application. If the user has obtained a digital 

disable that particular suggestion. Entering the preferences certificate, then the "encrypt" and "sign" options are set in 

option from the file menu on the menu bar resets the IHP. addition to the other pre-set options. These pre-set options 

The File menu (FIG. 5, top line) contains nine sub-menus: are outgoing compression and the Interactive Help Panel, 
exit, get messages, create, preferences, compress/ The user can select the options that he/she prefers. If a 
decompress folder, display, filters, certificate book, and 60 user doesn't wish to use the Interactive Help Panel, that 
print. This menu option provides some miscellaneous func- option can be disabled by checking the checkbox "Interac- 
tions of the applications that don't fit in the other menu tive Help Panel Settings" heading. In order to restore the 
options. Interactive Help Panel to the default functionality, the user 

If exit is chosen from the File menu, the application would click the "Reset Interactive Help Panel" button. The 

determines what state it is currently in. If the application is 65 user also has the availability to enable/disable encryption, 

in the compose state, the user is prompted to save the current digital signatures, attachment compression, signature file 

draft to the Draft List from the Interactive Help Panel. If the appending, and outgoing message options. When the user is 
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finished selecting and/or deselecting the available options, 
he/she may exit the preferences display by selecting the 
"Exit Preferences" button. When this button is pressed, the 
application moves to the prior state of the application. That 
is, if the user was in a different state, such as composition, 
that state would return to the display, assuming the exact 
information that was there when the user entered the pref- 
erences state. It is important to note that the selection of 
certain options from the preferences display does not affect 
the previous state of the application. Thus, if the user was 
composing a message before entering the preferences state, 
and then changed the encryption settings, these changes 
would be noticed, not on the current composition, but on the 
next composition. 

The View Certificates component allows the user to view 
and control the various certificates that are stored in the 
certificate book (FIG. 8). The user can view certificate 
information, revoke certificates, and determine those certifi- 
cate authorities that they trust. 

The dialog, as displayed in the third window of the 
application, contains a text box, instructions, and seven 
buttons. The four buttons lined along the top of the text box 
display certificate listings for various entities: Certificate 
Authorities (CAs), other people, the user's certificate, and 
the Certificate Revocation List (CRL). When one of these 
buttons is selected, the text box of the dialog displays the 
appropriate certificates to the user as a list. To view a 
certificate, the user highlights that certificate within the text 
box and then clicks the "View" button. Then the certificate 
information replaces the certificate list. The user also is able 
to revoke certificates by first highlighting the certificate from 
a list presented in the text box, then clicking the "Revoke" 
button. When the user is finished with the certificate book, 
he/she clicks "Done" to return to the previous state. That is, 
if the user was composing a message when they entered the 
certificate book, then that composition reappears when the 
user exits the certificate book. 

The Display option gives the user the ability to change the 
appearance of the application in general. Options include 
any images that are available on the application, as well as 
windowing properties (i.e. frame color, etc.). 

Selection of the "Filters" option from the file menu 
displays a filter dialog in the third window of the application 
(FIG. 9). This dialog allows the user to create, modify, 
and/or delete existing e-mail filters. 

The user adds a message filter by entering a filter name, 
the constraint field of the filter, what the field should contain 
in order to be filtered, and a folder in which to place the 
messages meeting the requirements of the filter. The con- 
straint fields are those fields found in the header of an e-mail 
message, such as "to", "from", and "cc". The user can select 
any number of containments for the field, the most common 
being either part or all of an e-mail address. The pull down 
menu lists the current folders in the Message Book, and 
contains a selection that allows the user to create a new 
folder from within this display. This display cannot be 
entered if the application is currently running a critical 
function. 

The address book menu (in the top line of the tool bar) 
contains one sub-menu: modify. The address book is dis- 
played (FIG. 10) in terms of Address Sheets and Address 
Lists in the second window of the application, and the dialog 
for manipulating the address book is shown in the third 
window of the application. 

The Modify option is not available to the user if the 
application is currently running a process. Selecting the 
Modify option brings up a dialog box that guides the user 
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through the process of adding, modifying, and/or deleting an 
address to the address list, which is displayed to the right in 
the second window of the application (FIG. 10). As the 
image indicates, the user is able to both add and modify 

5 address sheets for correspondents directly from this dialog 
box as well as add and/or delete address folders. If the user 
wishes to add an address to the Address Book, he/she enters 
the relevant information in the text boxes labeled, Name, 
E-mail, Phone, Fax, Address Fields, and Notes. Then the 

10 user selects the address folder in which to place the new 
address from the pull down list located in the lower center 
area of the GUI. To complete adding the new address, the 
user simply clicks the "Add to:" button. 

If the user would want to modify an existing address, 

15 he/she first highlights the address name shown in the second 
window of the application (far right). When he/she high- 
lights the address listing, the user then sees the full infor- 
mation for that address appear in the text boxes of the dialog 
box. The user can then make the appropriate changes to the 

20 information, and then click the "Add to:" button to replace 
the old address with the new one. A prompt is placed in the 
Interactive Help Panel before the old address is actually 
replaced, to confirm the user's desire to perform that action. 
When the user is finished modifying the address book, 

25 he/she can exit the dialog by selecting "Done". When this 
button is selected, the application moves back to its previous 
state. Thus, if the user was composing a message, then the 
composer is displayed with the previous information con- 
tained in that display maintained. 

30 The pull down list that displays the current folders has an 
option that allows the user to type a new folder directly into 
that box. Then, when the user presses the "Add to:" button, 
this folder is created, and then the new address is placed into 
that folder. This method of adding a folder to the address 

35 book can also be used to create a folder containing no new 
address. When the user wants to add only an address folder, 
then he/she leaves all of the text boxes blank, types the name 
of the new folder in the pull-down menu, and then clicks the 
"Add To:" button. 

40 Furthermore, if the user wants to delete an address from 
the Address Book, he/she first highlights the address in the 
second window of the application, and then clicks on the 
"Delete Selection" button below the "Notes:" text box. The 
application then prompts the user via the Interactive Help 

45 Panel to ensure that the user would like to carry out this 
action. 

The Account Book selection (in the top line of the tool 
bar) also contains just one submenu: modify. The e-mail 
account book is displayed in terms of Account Sheets and 

50 Account Lists in the second window of the application. 
When the Modify option is selected, the application 
displays the dialog box of FIG. 11. If the application is 
currently running a critical process, then this option is not 
available to the user until that process is complete. This 

55 dialog box guides the user through the process of adding/ 
deleting/modifying an existing e-mail account, and/or 
adding/deleting a folder to the account book. 

When the user wants to add a new e-mail account to his 
or her account book, then the user first enters the appropriate 

60 information in the supplied text boxes labeled: User name, 
Password, and Server. The user name field holds the user's 
name on that account, the password field holds the password 
the user must supply to access the account, and the server 
field holds the name of the server on which the account 

65 resides. The password field is "blind," that is, rather than 
printing what the user types, the only characters that show 
up are asterisks (*). When the user wants to modify an 
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account (as when the user has modified the password), then 
the user is required to highlight the account in the account 
list displayed at left. When this is done, the account infor- 
mation is placed into the appropriate text boxes. When the 
user wants to delete an account or folder, the user first 
highlights the account, then clicks on the delete button. 

When the user would like to create a new folder, he/she 
uses the pull down menu to type a new folder name. The user 
needn't supply account information to create a new folder, 
although this option is available in the event the user would 
like to place a new account in a new folder. In this, and every 
case listed above, the user is prompted by the Interactive 
Help Panel at the lower right of the application to confirm 
the addition/deletion operation. 

When the user is finished manipulating the Account Book, 
then the user must select the "Done" button to exit the 
display and return to the previous state of operation. Thus, 
if the user was composing a message, the composer is 
displayed having maintained all of the information the user 
may have entered into that display. 

The Help menu (top line of the tool bar) contains an 
online help reference, a brief tutorial, and an "about" section 
that lists that application's version, completion date, etc. If 
the application is currently executing a critical process, then 
these options are not available until the process is complete. 

The Tutorial option brings up a dialog box as in the 
preceding examples, but provides one large text box with a 
chapter listing, back and forward buttons, and an exit button. 
The layout of the dialog is similar to the one displayed in 
FIG. 12, and the text of the tutorial is shown in the large text 
box. The user is able to view the different chapters of the 
tutorial, or view an index (this option is included in the 
chapter pull down menu). When in each chapter, the user is 
able to utilize the back and forward buttons to move either 
forward or back a page. If the user selects the exit button, 
then the application closes the tutorial and automatically 
returns to the start state. 

When the Online Help option is selected, an online index 
appears in the third window of the application. At the user's 
disposal is an index of common words/features/lists/terms or 
other useful "guiding" words that the user may want to 
search for. When the user highlights one of these options in 
the index, the help listings from the tutorial are displayed 
below so the user can select one of the options. 

The About selection displays information regarding the 
current version of the application. The information is dis- 
played in the Interactive Help Panel so that no other option 
or operation is disrupted. Included in the About display is the 
version number of the application, the date of its release, and 
contact information (including Web information). This 
option is not available when the application is running a 
critical process. 

The Create button (second line of the tool bar) brings up 
the composition screen (FIG. 13). This screen is placed into 
the third window of the application. The preferences are read 
such that the application understands the user's desire to 
encrypt, sign, and/or compress the outgoing message or its 
attachment, if any. This button does not operate if the 
application is currently running a critical process. This 
screen is where the user composes outgoing messages. 
When the user is satisfied with the composition and is 
finished editing the composition, the user presses the "Send" 
button (described below) to complete the action. Five addi- 
tional buttons are shown: Attach File, Save as Draft, Sig- 
nature File, Spell Check, and Cancel, 

r Vha Attach File button, when clicked (on the tool bar in 
the frame), brings up a dialog box (the only separate window 
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used by the application) in order to allow the user to select 
a file that he/she wishes to attach. The file can be of any type 
and size, if the user has the proper permissions to access and 
download the file. The dialog box that this option displays is 

5 a familiar Windows file dialog box. It supplies a directory 
tree, a name field, a pull down menu of available disk drives, 
etc. When a file is attached, it is placed into a buffer and 
waits for the send or "Save as Draft" button to be selected 
for proper handling. When the user has completed selection 

1Q of the desired attachment, the file dialog exits and the user 
may continue editing the composition. This option is not 
operational if the application is currently running a critical 
process. . 

If the user selects the "Save as Draft" button, then the 
application acts as though it is sending the message, but 

15 rather than sending the message over the Internet to the 
desired address, the message is placed in the Draft folder of 
the Message Book. Thus, the message and any attach me nt(s) 
are properly formatted for sending, including any 
encryption, signature, and/or compression requirements. 

20 When the application is finished with this operation, the start 
state of the application is displayed. 

A user, by selecting the Signature File button, from the top 
line of the Composer frame tool bar, can create and/or 
manipulate a signature file as well as enable or disable the 

25 option to append a signature file to outgoing messages (see 
FIG. 14). This option requires that a new dialog box be 
shown to the user. As such, the old dialog box (FIG. 13) is 
hidden rather than closed, so that the user does not lose any 
information already placed in the composition of the mes- 

30 sage. This option is not available when the application is 
currently running a critical process. This display is a simple 
one that provides the user with some instruction. If a 
signature file has been created, then the application displays 
that file in the text box (contained in the third window of the 

35 application). If the user has not yet created a signature file, 
then the user can create one by entering the desired signature 
in the text box, then clicking on Create Signature. This 
action makes the file available to the application by saving 
the file to disk. 

40 If the user has already created a signature file, but wishes 
to modify that signature file, then the user first makes 
modifications, then selects the Modify Signature button to 
save those changes. When the user would want to enable or 
disable the signature file, then he/she marks the checkbox. If 

45 the box is marked, the file is enabled. If the user would like 
to exit with or without making changes to the signature file 
and its operation, then the user simply clicks on the Return 
button to go back to the Create display. 

The Cancel option provides the user a way to exit a 

50 composition. When this option is selected, the display 
returns to the application's start state, and all information 
regarding the current composition is lost. This option is not 
available to the user if the application is currently running a 
critical process. 

55 When the user selects the "Retrieve Messages" button 
from the second line of the tool bar (FIGS. 5-14, second fine 
of tool bar), the application gets messages from the user's 
various e-mail accounts. The first account to be checked is 
the account found on the EMC server. If the user has other 

60 accounts listed in his or her e-mail account book, these will 
be checked in the order in which the user entered them. Note 
that only default accounts will be checked automatically. 
Any other accounts must be checked for messages manually. 
For each account that is checked, the message filter will be 

65 invoked. The slate of the application remains the same 
except for the second window, which changes to display the 
message book. 
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The Encrypt | Sign | Compress check-box options (FIGS. 
5-14, second line of tool bar) allow the user to select, for 
each composition, the appropriate action for the application 
to take when sending a composed message. When the 
application is run, the preferences of the user are read and 
these options would be run accordingly. The availability of 
the options at the time of composition provides the user with 
the ability to change his or her mind for each message. If an 
option is marked, then it is enabled. Thus, if the Encrypt 
option is checked, the next outgoing message is encrypted. 
If the user changes any of these options for a given message, 
then the application changes the options to such preferences 
after the current composition is sent, saved as a draft, or 
canceled. 

The Address Book | Account Book | Message Book radio 
buttons (FIGS. 5-14, second line of tool bar) allow the user 
to toggle between the Account, Address, and Message 
Books. Only one option can be displayed at any one time. 
These arc shown in the second window of the application in 
a hierarchical fashion. If the user would want to return to the 
Message Book, he/she highlights a folder in the first window 
of the application. These options are not available if the 
application is currently running a critical process. 

The user can bring up the Address Book or Account Book 
dialog when he/she double clicks on a particular address or 
account or folder. If the user would like to send an e-mail 
message directly from the address book, the user first 
highlights that address (or address folder for a "bulk" 
mailing), then selects the "Create" button contained in the 
main window of the application. If the application is cur- 
rently in another state, such as the composition state, then 
that display is simply hidden from view rather than 
destroyed. Similarly, the user is able to view any message 
from the Message Book by double clicking on that message 
in the message book. This displays the Message Book 
Display as previously described. 

The Web-based application cannot be contained in a 
single unit, per se, as the client-side application is. Rather, 
the application spans from the client to the server. Known 
Web-based e-mail providers have not had, or even attempted 
to implement, security measures such as the X.509 certifi- 
cate standard. In the case of the Web-based application of the 
present invention, the application runs as a distributed 
system. That is, the application controls are sent to the user 
to be viewed on the user's browser, and through these 
controls the user operates the application that resides on the 
server. 

The functioning of the Web-based application takes place 
primarily on the server side of the application, and the 
controls are passed through a secure channel using the 
Secure Sockets Layer protocol ("SSL"), or some other 
security protocol offering a secure "pipe" to and from the 
application level. Thus, all certificate information and initial 
message information is secured on the user's account as it 
exists on the mail server. This approach provides a fully 
accessible, secure e-mail application that the user can utilize 
from any web-enabled computer anywhere in the world, 
within legal boundaries. 

Some components of the application must be ported to the 
user's machine at each mail session, such as the compression 
tools. The porting of this component minimizes the band- 
width usage of the user from the local machine. Depending 
upon size, some other components may be downloaded to 
the browser on a per-session basis. Often, users of Web- 
based e-mail wish to place attachments on their outgoing 
mail and/or download messages that they have received for 
printing or some other purpose. The Web-based application 
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running in the browser provides a way for the user to access 
and download messages to his or her local machine, as well 
as upload attachments for sending. The user also has the 
capability to download messages to the local machine and 

5 store them in a provided message book. 

In use and operation, a premium -service subscriber to the 
EMC service, User A in FIG . 1, has a choice of accessing his 
e-mail through either his personal computer A or through 
another computer X, as shown. Computer A has the EMC 

10 program loaded onto it, and computer X does not. User A 
can use computer A to compose a message, to add anv 
attachments, to set the e ncryption of the messag e and the 
encryption and compression or not of anv attachments, e tc., 
and tn^i ^n the m essa ge digitall y or not, all while off-linejlb 

as send the message and any others, and to check and receive 
any messages sent to him by others, he/she connects over a 
tele phone or cable line, or any other hard-wired or wireles s 
connection, to his ISP's Server I. That server is licensed by 
the present inventors and also has the EMC system installed. 

20 Server I confirms the identity and digital signature of the 
subscriber and accepts the message uploaded from Com- 
puter A along with any attachments. User A can use com- 
puter A from home or the office or on any other Internet 
connection, as when he/she is travelling with a laptop or 

25 notebook computer A. 

If User A is away from home or office and cannot use his 
Computer A, he/she still can send and receive e-mail with all 
the information and options of his home Computer A. 
He/she need only log onto Server I from any computer with 

30 suitable hardware and software, as Computers X or Z as 
shown. Computer X connects to his own Server I, while 
Computer Z connects to a Server III, as shown, which does 
not have EMC loaded or licensed, but does practice the 
S/MIME protocol. In either case User A logs into Server I 

35 using his user and/or identification name(s) and password; if 
he/she is on Server III he/she merely needs to access Server 
I through the Internet. He/she is able to compose mail 
on-line, and receive mail, with all the same encryption, 
authentication, etc. features, settings, and organization as 

40 he/she had on his own Computer A. 

A message sent by User A to another EMC subscriber, as 
User B, is routed from the Computer A or Computer X 
through Server I and over the Internet (and possibly over or 
through other servers there) to a Server II of User B. It is 

45 stored there, in the EMC Web system application, with any 
attachments and in any encrypted form used by User A, until 
User B logs on to retrieve that message. If User B uses 
his/her regular Computer B with EMC loaded, he/she may 
download the message, have it automatically decrypted, and 

50 any attachments decompressed, if necessary, for reading 
off-fine. If User B uses a different computer, as Computer Y, 
through Server II, he/she must remain on-line to read the 
message, although it will be decrypted and any attachments 
decompressed for her by Server II as part of the EMC 

55 program and service, 

A message sent by User A to a non-EMC subscriber, as 
User C, is routed from Computer A or Computer X through 
Server I and over the Internet (and possibly over or through 
other servers there) to a Server III of User C. It is stored 

60 there, in the Web-based e-mail application of User C (as 
Hotmail®), with any attachments and in any encrypted form 
used by User A, until User C logs on to retrieve that 
message. Whether User C uses his regular Computer C or 
another Computer Z, neither one having EMC loaded, 

65 he/she may download the message and have it automatically 
decrypted under the S/MIME protocol. However, for any 
attachments that are compressed, User C must go to a 
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different program to decompress and read them. If User C 
has a client-side e-mail system (as Eudora®), he/she would 
download the message and attachments and can then read 
and otherwise manipulate them off-line. 

If User A wants to send a message to a user not on a secure 
server or computer, i.e., not using S/MIME or similar 
protocol, he/she may do so, but the message and attachments 
will not be encrypted (User A will be warned of this by the 
EMC system). Interoperability is an important feature of this 
invention, so that subscribers can communicate electroni- 
cally to all other persons, not just to those on a particular 
system. 

To receive e-mail messages from others, User A opens his 
client-side program on Computer A, or logs into Server I 
from any other Computer X or Z connected to any Server. 
He/she downloads the messages to his Computer A, or reads 
them on-line on the other Computer X or Z. The messages 
are decrypted automatically, attachments are decompressed 
automatically if necessary, and other features of the EMC 
program are implemented for him, since he/she is tied into 
Server I, which runs the web-side EMC system. 

Many variations may be made in the invention as shown 
and its manner of use without departing from the principles 
of the invention as pictured and described herein and 
claimed as our invention. "Personal computer" as used 
herein refers to computers of all manufacturers and operat- 
ing systems, whether PC, Apple, Unix, Java, Wintel, etc. 
Minor variations will not avoid the use of the invention. 

We claim as our invention: 

1. A method of providing a secure electronic messaging 
service to each of a plurality of subscribers, using a server 
and a personal computer both connected to a global com- 
puter network, the method comprising the steps: 

programming each of a server application and a personal 
computer application with a secure e-mail messaging 
service configured to interact with and to shadow the 
other application via said network as to personal 
information, settings, and files of an individual one of 
said subscribers; 

storing said information, settings, and files both on said 
server and on said personal computer running said 
application, for access off-line solely through the per- 
sonal computer of said subscriber and for access 
on-line by said subscriber through any computer having 
capability to communicate with said server; 

allowing access to said messaging service via said server 
for a subscriber's sending and receiving electronic 
messages; and 

providing a digital certificate security service from each 
of the server and the computer together- with the 
messaging service. 

2. The method of claim 1, wherein the step of accessing 
the server of the messaging service from a personal com- 
puter using the Web-based form of service further comprises 
the step of using an S/MIME compliant application to 
connect between the computer and said server. 

3. The method of claim 1, wherein the step of providing 
a digital signature security service includes verifying the 
identity of the sender, the integrity of the message, and the 
fact of the sending by the sender. 

4. The method of claim 1, further including the step of 
decompressing automatically a compressed attachment to a 
message upon its reaching and being opened by a subscriber. 

5. A method of providing secure e-mail service to a 
subscriber, the service being accessible equally from an 
e-mail program on a computer of the subscriber and via the 
Internet (a global computer network) from other computers 
which may be used by the subscriber, the method comprising 
the steps: 

loading the e-mail program onto the subscriber's 
computer, the program being one for composing and 
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displaying e-mail messages thereon while the computer 
is off-line, using personal information, settings, and 
files of the subscriber and for providing at least one of 
address, e-mail account, and message book features; 

5 providing an e-mail service on an Internet server acces- 
sible by said subscriber, the service and the program on 
the subscriber's computer each shadowing the content 
of the other for said personal information, settings, and 
files of the subscriber and for each of the address, 
account, and message books of the subscriber; 

10 allowing access to the e-mail service on said subscriber's 
computer and from any other computer via a modem or 
the Internet; 

synchronizing and updating the personal information, 
settings, and files of the subscriber and the features and 
is content in the subscriber's program and in the e-mail 
service on the Internet server upon each access of the 
subscriber's computer to the Internet server and e-mail 
service after a change in either, and 
providing from each of the e-mail server and the user's 
20 computer, with one or more messages a digital signa- 
ture security service for verifying the identity of the 
sender, the integrity of the messages sent, and the fact 
of the sending by the sender, 
whereby to provide nearly identical, secure e-mail services 
25 to the subscriber whether the subscriber is using his/her own 
computer which is running the application or is logged-in to 
the server from a different computer through the Internet. 

6. The method of claim 5, wherein the step of accessing 
the e-mail service from a computer other than the subscrib- 

30 er's computer further comprises the step of using an 
S/MIME compliant application to connect between the other 
computer and the server. 

7. The method of claim 5, further comprising the step of 
decompressing any compressed attachment automatically 
when it reaches and is opened by a subscriber. 

35 8. A secure, encrypted, digitally-certified e-mail service 
application for a personal computer that is also accessible 
for similar use over a global computer network, the service 
application comprising: 
a full-featured e-mail program for loading onto a sub- 
4 ° scriber's personal computer, the program configured to 
receive personal information, settings, and files of the 
subscriber and having at least one of address book, 
e-mail account book, and message book files provided 
therein; 

45 a network-based e-mail service system configured to 
shadow the subscriber's e-mail program as to content 
and having the same ones of address book, account 
book, and message book files as said program on said 
personal computer, the system synchronizing and 

5 0 updating itself and the program on the personal com- 
puter as and after either is changed and upon connect- 
ing the subscriber's personal computer to the e-mail 
service system via a modem or the network, and 
means for providing a digital signature security service 

55 directly from either of the subscriber's computer or the 
network server, the signature service verifying the 
identity of the sender, the integrity of the message, and 
the fact of the sending by the subscriber. 

9. The e-mail service application of claim 8, wherein the 
server of the e-mail service is configured for access to any 

60 computer used by the subscriber using an S/MIME compli- 
ant application. 

10. The e-mail service application of claim 8, wherein the 
service further is configured to decompress any compressed 
attachment automatically when it reaches and is opened by 

65 the subscriber. 

* * * * * 
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ABSTRACT 



A technique manages packets in a data communications 
device having a memory using a real-time feedback signal. 
The technique involves transmitting an initial set of packets 
from the data communications device. The technique further 
involves monitoring transmission of the initial set of the 
packets from the data communications device, and provid- 
ing the real-time feedback signal indicating transmission 
information regarding the initial set of packets. Additionally, 
the technique involves manipulating a new set of packets 
within the memory of the data communications device based 
on the real-time feedback signal, and transmitting the new 
set of packets from the data communications device based 
on how the new set of packets was manipulated within the 
memory of the data communications device. The use of the 
real-time feedback signal enables the data communications 
device to make on-the-fly adjustments to dynamically 
changing traffic patterns without the need for human inter- 
vention. 

27 Claims, 7 Drawing Sheets 
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METHOD AND APPARATUS FOR 
MANAGING PACKETS USING A REAL-TIME 
FEEDBACK SIGNAL 

BACKGROUND OF THE INVENTION 

A typical data communications network includes a num- 
ber of host computers linked by one or more data commu- 
nications devices coupled via any type of transmission 
media. Data is transmitted between one or more hosts on the 
network in the form of network packets or cells which 
typically have a predefined, standardized format 

In some networks, network packets are classified into 
different Quality of Service (QoS) classes which dictate how 
competing traffic flows are allocated resources which effects 
how quickly such packets travel from their sources to their 
destinations. 

In such a network, data communications devices (e.g., 
routers and repeaters) typically receive and retransmit net- 
work packets based on the QoS classes of the packets. For 
example, in a network having video packets as a first QoS 
class and email packets (electronic mail) as a second QoS 
class, a network router may internally manage packets such 
that received video packets are retransmitted with less delay 
than email packets. As a result, network packet destinations 
(e.g., receiving hosts) generally perceive different responses, 
or Qualities of Service, for different QoS classes (e.g., faster 
video transmissions than email transmissions). 

In a network which uses QoS classifications, data com- 
munications devices generally manage network packets 
internally according to packet management algorithms. 
Typically, in such a device, the algorithms provide control 
signals as a function of local network traffic data which has 
been accumulated and post-processed over an extended 
period of time. For example, a network router may operate 
in a particular manner based on local network traffic data, 
which has been accumulated and post-processed over sev- 
eral days, to enable the router to achieve QoS goals of 
transmitting received video packets with a maximum time 
delay of 100 ns and t ransmitting received email packets with 
a maximum ti me delay of 100 ms. 

Typically, a person known as a network administrator is 
responsible for ensuring that a data communications device 
(e.g., the router) achieves its QoS goals . When the data 
communications device does not provide adequate QqS, the 
administrator analyzes tbejtperation of the devic e relative to 
the local network traffic and attempts to improve the per- 
formance of the device to enable it to achieve its QoS goals. 
Furthermore, even if the device adequately achieves its QoS 
goals, the administrator may still attempt, on occasion, to 
further improve the performance of the device to enable it to 
more easily manage network packets and achieve its QoS 
goals. 

When the administrator attempts to improve a data com- 
munication device's ability to manage network packets, the 
administrator typically studies the network traffic passing 
through the particular point where the device is connected to 
the network. For example, the administrator may connect a 
network packet monitor at the input of the data communi- 
cations device to classify packet sizes, to count the number 
of packets in total or the number of packets of a particular 
QoS class received by the data communications device. 
Often, the administrator allows the monitor to accumulate 
this information over an extended period of time such as 
several hours or perhaps several days. For example, the 
monitor stores the size and count information in a computer 
file on a computer for future analysis. 
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After the count information has been collected, the 
administrator generates particular network metrics from the 
count information. For example, the administrator may have 
logged the amount of time that elapsed while collecting the 
count information. Accordingly, the administrator can deter- 
mine the overall packet rate provided by the data commu- 
nications device by dividing the counted overall number of 
packets by the elapsed time. That is, 



overall number of packets counted 

overall packet rate = 

elapsed time 



Similarly, the rate for a particular packet type can be 
determined by dividing the counted number of packets for a 
15 particular QoS class by the elapsed time. That is, 

number of packets counted 

for a particular QoS class 

packet rale for a particular = . 

20 packet type elapsed time 

In this manner, the administrator determines the character- 
istics of the network traffic handled by the data communi- 
25 cations device during the elapsed time period. This infor- 
mation along with packet size information can help improve 
understanding of the resource requirements of different 
traffic flows. 

After the administrator has determined the network traffic 
characteristics of the elapsed time period, the administrator 

30 examines the settings of the data communications device. In 
particular, the administrator verifies that the operating 
parameters of the data communications device are set such 
that the device will manage packets correctly and efficiently 
in the future, if the device encounters network traffic having 

35 the same characteristics. For example, if the device is 
already set to handle such traffic correctly and efficiently, the 
administrator leaves the parameters unchanged or may 
change the parameters slightly with the hope of improving 
performance. However, if the device is not set to handle such 

40 traffic correctly and efficiently, the administrator modifies 
the parameters such that the device will handle the traffic 
correctly and efficiently in the future. The size of the output 
queues of the data communications device and the priority 
of different packet types are examples of parameters that the 
administrator may examine and perhaps adjust. 

45 After the administrator has determined that the data 
communications device is properly set to manage packets 
correctly and efficiently and if the data communications 
device encounters new network traffic having different char- 
acteristics as previously encountered during the elapsed time 

50 period, the administrator may choose to subsequently repeat 
the above described procedure at some time in the future. 
For example, the administrator may (i) monitor the network 
traffic several days later to accumulate new size and count 
information, (ii) generate new network metrics using the 

55 new information, and (iii) then examine the settings of the 
data communications device relative to the newly generated 
network metrics. 

Using the above-described technique, the data communi- 
cations device is tuned to manage network packets correctly 

6Q and efficiently with the assistance of human intervention by 
the network administrator. With an aggressive approach 
towards fine tuning the data communications device, the 
administrator may repeat the adjustment process a dozen or 
so times over the course of a several days. 

65 SUMMARY OF THE INVENTION 

In contrast to conventional network packet management 
techniques, the invention is directed to techniques for man- 
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aging network packets in a data communications device the initial set of packets. The traffic monitor recognizes, for 

using a real-time feedback signal. In one technique, a traffic each sampled packet, a bit pattern of that packet, and updates 

monitor observes network packet traffic transmitted from an a set of data structures based on the recognized bit pattern of 

output of the data communications device, and generates the that packet, the data structures respectively corresponding to 

real-time feedback signal based on the observed traffic. The 5 the multiple packet classes. Furthermore, the traffic monitor 

data communications device manages newly received pack- generates the real-time feedback signal based on the updated 

ets according to the real-time feedback signal i.e., according ^ of data structures such that the real-time feedback signal 

to the relatively instantaneously observed traffic, thus is indicative of the transmission levels of the multiple packet 

enabling the data communications device to perform real- dasses for lhe ^ (or ious) K{ of ckeK 
time packet management and adjust to dynamically chang- _ ¥ , _ L f . 

ing conditions within the network at a rapid pace. 10 '? *« TOS arrangement, the real-time feedback signal 

° ... , 4 , e , . . preferably indicates a bit count for each of the multiple 

One embodiment involves the use of a data commumca- r , . : , t . . ... , A u »u j * 

.... t-u j . • packet classes, and a total bit count. As such, the data 

tions device having a memory. The data communications r . ' . . - , , . . . t ' . . 

, . & . .. . / c . 4 ... . communications device preferably includes traffic analysis 

device transmits an initial set of packets which are mom- . . 4 ., ,. t ' ' ~ t , u . . ' 

, , t ^ . £■ .u 'a l°g ic tnat provides a bit rate for each of the multiple packet 

to red by a traffic monitor. The traffic monitor then provides , u a .u u-. u e.u n- i i * 

/ . cut- , . . * . + . . . c ]5 classes based on the bit count for each ot the multiple packet 

the real-time feedback signal indicating transmission infor- , , . t , , t , 4 , t t , * c 

,. . . . • i < c , , T. classes and the total bit count such that the new set of 

mahon regarding the initial or previous set of packets. The ^ ^ ^ ^ oQ ^ bft fate for each Qf ^ 

data communications device manipulates (or handles) a new r . . . . 4 r . 

c . ... . , multiple packet classes, 

set of packets within its memory based on the real-time r r 

feedback signal, and transmits the new set of packets from 20 Preferably, the data communications device can request 

the data communications device based on how the new set information from the traffic monitor. In particular, the device 

of packets was manipulated within the memory. requests the information by generating a request signal for 

Preferably, each packet belongs to one of multiple packet information regarding the transmission levels of the multiple 

classes, e.g., Quality of Service (QoS) classes such as video, P ack f cl f ^ [ or the mihal l set of P ackets or an V P revious 

audio, general data and best effort classes. Classes may also 25 set of packets. In response, the traffic monitor generates the 

be defined by packet source, destination, or any other real-time feedback signal such that it includes the requested 

internal data in the packet, or by other information such as mtorma ion. 

a physical location (e.g., port) on the device upon which the 11 should be understood that network traffic patterns may 
packet arrived. As such, the real-time feedback signal indi- shift wilhin a relatively short period of time. As such, some 
cates transmission levels of the multiple packet classes for 30 conventional data communications devices may not be opti- 
the initial set of packets. For example, the real-time feed- mail y adjusted to manage a network traffic with particular 
back signal may indicate packet counts for each packet class characteristics if the adjustments are infrequent or if the 
in the initial set, and a total count for the number of packets adjustments rely on network data gathered over extended 
in the initial set periods of time. In contrast, the invention involves optimally 
The memory of the data communications device prefer- 35 how a data . communications device manages pack- 
ably stores a queue structure. As such, the data communi- ets ^ ased on a real-time feedback signal. Accordingly if the 
cations device manipulates the new set of packets by sched- ^ P attera shlfts Wlthl " a .relatively short period of time, 
uling each of the new set of packets in the queue structure the data communications device, configured according to the 
based on the transmission levels of the multiple packet invention, can adapt its operation to more optimally manage 
classes for the initial set of packets, as indicated by the 40 P ackets in a manner su P cnor t0 that done m *>™***™d 
real-time feedback signal. Alternatively, the device manipu- data communications devices. 

lates the new set of packets by reordering queues of the • Additionally, the invention provides for an automated 
queue structure when the transmission levels of the multiple adjustment process. That is, once configured in accordance 
packet classes for the initial set of packets, as indicated by with the invention, no human intervention is required to 
the real-time feedback signal, cause the data communica- 45 enable the data communications device to manage packets 
tions device to detect a reorder condition. As another correctly and efficiently within a network having changing 
alternative, the device manipulates the new set of packets by network traffic characteristics. Rather, the real-time feed- 
discarding a packet of the new set of packets from the queue bac ^ signal is generated in a contiguous manner enabling the 
structure when the transmission levels of the multiple packet data communications device to adjust its operation dynami- 
classes for the initial set of packets, as indicated by the 50 callv and automatically. 

real-time feedback signal, cause the data communications Furthermore, unlike conventional systems which have 

device to detect a discard condition. As yet another large storage requirements to store large amounts of network 

alternative, the data communications device manipulates the data gathered over extended periods of time and large 

new set of packets by performing multiple functions using processors to analyze the network data, the invention has 

the real-time feedback signal. For example, the device 55 relatively small hardware requirements. That is, since the 

schedules packets, reorders queues and discards packets, invention uses a real-time feedback signal that contains fresh 

based on the real-time feedback signal. In this arrangement, data, there are less memory requirements and processor 

information within the real-time feedback signal is prefer- demands. 

ably an input to an algorithm used by the device, as the Also, the invention enables different types of network 

device performs many complex calculations. eo information to be gathered on-the-fly. That is, if the inven- 

Preferably, each packet includes a bit pattern indicative of tion cannot determine how to adjust itself in view of 

one of the multiple packet classes. The bit pattern resides in particular network data acquired from the traffic monitor, the 

a predetermined location within each packet, i.e., within a invention can request other types of network data to assist 

type of service (TOS) field (e.g., indicating the QoS assigned the invention in its determination of how to adjust itself, 

to that packet). As such, to monitor transmission of the initial 65 Accordingly, there is less likelihood that conflicting goals 

set of the packets and provide the real-time feedback, the will result in oscillating performance. That is, the invention 

traffic monitor preferably samples (monitors) packets from will tend towards a convergence or compromise between the 



01/05/2004, EAST Version: 1.4.1 



US 6,449,255 Bl 



different goals (e.g., QoS goals). Hence, a first action by the 
invention based on a particular goal may provide only a 
modest performance improvement, and a subsequent action 
based on a different goal may provide a substantially better 
improvement in a non-oscillating manner. 

BRIEF DESCRIPTION OF THE DRAWINGS 

The foregoing and other objects, features and advantages 
of the invention will be apparent from the following more 
particular description of preferred embodiments of the 
invention, as illustrated in the accompanying drawings in 
which like reference characters refer to the same parts 
throughout the different views. The drawings are not nec- 
essarily to scale, emphasis instead being placed upon illus- 
trating the principles of the invention. 

FIG, 1 is a block diagram of a data communications 
device according to an embodiment of the invention. 

FIG. 2 is a block diagram of a traffic monitor of the data 
communications device of FIG. 1. 

FIG. 3 A is a block diagram of a network packet that is 
suitable for use by the data communications device of FIG, 
1. 

FIG. 3B is a block diagram of an alternative network 
packet that is suitable for use by the data communications 
device of FIG. 1. 

FIG. 4 is a flow diagram illustrating the operation of a 
management module of the data communications device of 
FIG. 1. 

FIG. 5 is a flow diagram illustrating the operation of a 
traffic analyzer of the data communications device of FIG. 1. 

FIG. 6 is a flow diagram illustrating, by way of example, 
a series of operations of a management module of the data 
communications device of FIG. 1 in response to different 
types of traffic information. 

FIG. 7 is a block diagram of a data communications 
device according to an alternative embodiment of the inven- 
tion. 

DETAILED DESCRIPTION OF PREFERRED 
EMBODIMENTS 

Overview 

The invention is directed to techniques for managing 
network packets using a real-time feedback signal. FIG. 1 
shows a data communications device 10 that connects to a 
network 12, and manages network packets 14 using such a 
real-time feedback signal in accordance with the invention. 
The data communications device 10 includes network 
packet management modules (16, 18, 20), output circuitry 
(22, 24) and monitoring circuitry (26). The management 
modules include an input scheduler 16, a reorder manager 18 
and a discard manager 20. The output circuitry includes 
memory (or output queue) 22 and an output scheduler 24. 
The monitoring circuitry includes a traffic monitor 26. 

When the data communications device 10 is in operation, 
network packets 14 flow from a portion of the network 12 to 
the input scheduler 16, through the memory 22, then through 
the output scheduler 24, and finally into a different portion 
of the network 12. The traffic monitor 26 preferably con- 
nects to the network 12 at an output of the data communi- 
cations device 10, and observes the network packets 14 
transmitted from the output scheduler 24 without interfering 
with the flow of network packets 14 back into the network 
12. 

Prior to beginning normal operation, the data communi- 
cations device 10 forms a queue structure 28 in the memory 
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22. The queue structure includes multiple queues 30- A, 
30-B, 30-C, 30-D, . . . (collectively queues 30) which 
correspond to different types of service (TOS) supported by 
the network 12 and the data communications device 10. In 
one embodiment, the different types of service are different 
Quality of Service (QoS) classes. By way of example, the 
data communications device assigns queue 30-A to a best 
effort QoS class, queue 30-B to a general data QoS class, 
queue 30-C to an audio QoS class, and queue-30-D to a 
video QoS class. 

As the input scheduler 16 receives packets 14 from the 
network 12, the input scheduler 16 schedules the packets 14 
within the queue structure 28 of the memory 22. In 
particular, the input scheduler 14 identifies the TOS of each 
packet 14, and then places that packet 14 in the queue 
assigned to that TOS (e.g., one of the queues 30-A through 
30-D). As a specific example, when the input scheduler 16 
identifies a particular packet 14 as a video packet, the input 
scheduler 16 places the video packet in queue 30-D which 
is assigned to the video QoS class. 

In addition to the input scheduler's ability to schedule 
packets 14, the input scheduler 16 has the capability to 
control the size of each queue 30 in an on-the-fly or dynamic 
manner based on a real-time feedback signal 38 provided by 
the traffic monitor 26. The input scheduler 16 analyzes 
network traffic data in the real-time feedback signal 38, and 
adjusts sizes of the queues 30 if the input scheduler 16 
determines that such an adjustment would enable the data 
communications device 10 to improve its performance. For 
example, using the real-time feedback signal 38, the input 
scheduler 16 may determine that there is excess bandwidth 
available yet general data packets are being discarded by the 
discard manager 20 due to the small size of queue 30-B. In 
such a situation, the input scheduler 16 may decide to 
increase the size of the queue assigned to temporarily store 
general data packets (e.g., queue 30-B). With such an 
adjustment, the data communications device 10 may be able 
to handle transmission of all of the general data packets and 
without a need to discard packets. 

The reorder manager 18 controls the prioritization of the 
queues 30 within the queue structure 28. In particular, using 
the real-time feedback signal 38, the reorder manager 18 
attempts to order the queues 30 in a manner that enables the 
data communications device 10 to easily achieve certain 
TOS requirements. In the example, the TOS requirements 
are pre-established QoS goals that enable packet destina- 
tions to perceive certain respoases associated with different 
QoS classes of packets. Accordingly, in the example, the 
reorder manager 18 of the data communications device 10 
reorders the queues 30 to enable the data communications 
device 10 to achieve predetermined Quality of Service 
(QoS) goals based on traffic data stored within the real-time 
feedback signal 38. 

The discard manager 20 controls deletion or discarding of 
55 packets from the queues 30. In particular, using the real-time 
feedback signal 38, the discard manager 20 determines when 
the data communications device 10 is unable to achieve its 
TOS goals, and discards packets in such situations in order 
to achieve such goals. In the example, the discard manager 
60 20 may determine from the real-time feedback signal 38 that 
the data communications device 10 is not providing video 
packets in accordance with pre-established QoS goals. In 
response, the discard manager 20 may begin discarding best 
effort packets from the queue (e.g., queue 30-A). As a result, 
more bandwidth becomes available for the video packets, 
and the data communications device 10 is now able to 
achieve its QoS goals. 
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In one embodiment, the input scheduler 16, the reorder 
manager 18 and the discard manager 20 use a same instance 
of the real-time feedback signal 38 (e.g., instance 39) when 
in operation. In another embodiment, the input scheduler 16, 
the reorder manager 18 and the discard manager 20 use 
respective instances of the real-time feedback signal 38 to 
operate asynchronously relative to each other. The latter 
allows for improved flexibility and customization. 

The output scheduler 24 transmits packets 14 (e.g., as a 
serial bit stream) from the queue structure 28 back into the 
network 12. Simultaneously, the traffic monitor 26 monitors 
the transmitted packets 14 (e.g., by identifying patterns in 
the serial bit stream) and generates a total count of all the 
packets transmitted as well as individual packet counts for 
each TOS. In the example, the traffic monitor 26 generates 
a total packet count and a count for each QoS class. In more 
sophisticated implementations, the traffic monitor 26 also 
reports packet sizes. 

It should be understood that the traffic monitor 26 is 
ideally located at the output of the data communications 
device 10 to measure the output traffic provided by the data 
communications device 10. Accordingly, the traffic monitor 
26 makes direct observations of the data communications 
device's operation and performance, and the traffic data 
within the real-time feedback signal 38 accurately reflects 
the device's operation and performance. Such an arrange- 
ment is superior to conventional arrangements that monitor 
network traffic at the input of a data communications device 
since monitoring the traffic at the input provides no indica- 
tion of how successfully the device handles the traffic. 

For example, suppose packets of a particular QoS class 
begin to accumulate in a data communications device queue. 
If the queue begins to overflow, a conventional data com- 
munications device may handle the situation by discarding 
packets to alleviate the congestion. However, with the 
invention, the traffic monitor 26 observing the output of the 
data communications device 10 may determine that other 
QoS classes are overutilizing the output scheduler 24 thus 
preventing the particular QoS class of packets from being 
transmitted. In this situation, the data communications 
device 10 may then temporarily reprioritize the overflowing 
queue to a higher priority to provide the overflowing packets 
greater bandwidth to transmit in order to alleviate the 
congestion problem. Such reprioritization is a more efficient 
and effective solution which is overlooked by conventional 
devices. Further details of various portions of the data 
communications device i0 will now be provided. 
Traffic Monitor 

As shown in FIG. 2, the traffic monitor 26 includes a 
pattern recognizer 42, a controller 44, multiple individual 
counters 46-1, 46-2, . . . , 46-N (collectively counters 46), 
and an aggregate counter 48. Before the data communica- 
tions device 10 begins normal operation, the traffic monitor 
26 assigns one of the individual counters 46 to each TOS. 
Then, during normal operation, the traffic monitor 26 
observes packets 14 as they are transmitted from the output 
scheduler 24, and updates the counters 46,48 such that they 
indicate the observed network traffic leaving the data com- 
munications device 10. In one embodiment, the packets 14 
are transmitted from the output scheduler 24 as a serial bit 
stream, and the pattern recognizer 42 identifies patterns 
within the serial bit stream to detect packets and to deter- 
mine the TOS of each detected packet. 

In the above QoS example, prior to normal operation, the 
traffic monitor 26 assigns an individual counter 46 to each 
QoS class (e.g., video, audio, general data, and best effort). 
Then, during normal operation, the pattern recognizer 42 
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scans a class indicator field (i.e., the TOS field) of each 
packet 14 to determine the QoS of that packet 14. The 
controller 44 then updates the appropriate counter 46 (i.e., 
the counter 46 corresponding to that QoS) and the aggregate 
counter 48. By way of example, for a video packet 14, the 
controller 44 increments a corresponding one of the counters 
46 and the aggregate counter 48. 

FIG. 3 A shows a format 50 for a network packet 14 that 
is suitable for use by the invention. The network packet 
format 50 includes a data portion 52 and a header portion 54. 
The header portion 54 includes a class indicator field 56 
(e.g., bit positions 8-11) that indicates the TOS (e.g., the 
QoS class for that packet). By way of example only, a class 
indicator of xOOll indicates video QoS, a class indicator of 
xOOl indicates audio QoS, a class indicator of xOOl indicates 
general data QoS, and a class indicator of xOOOO indicates 
best effort QoS. 

FIG. 3B shows an alternative format 58 for a network 
packet 14 that is suitable for use by the invention. The 
network packet format 58 is similar to the network packet 
format 50 except that a data portion 60 of the network packet 
format 58, rather than a header portion 62, stores a class 
indicator 64. Accordingly, the class associated with a net- 
work packet may be determined by an analysis of the actual 
data carried by that packet. 

As the pattern recognizer 42 monitors network traffic on 
the output of the data communications device 10 and the 
controller 44 updates the counters 46,48, the controller 44 
simultaneously generates the real-time feedback signal 38 
and sends the signal 38 to the network packet management 
modules. In one embodiment, the controller 44 generates 
and sends the real-time feedback signal 38, as a digital 
signal, automatically (e.g., every 1 ras) to enable the net- 
work packet management modules (16, 18, 20) to dynami- 
cally adjust the manner in which they manage packets within 
the data communications device 10 (e.g., instance 39 in FIG. 
1). Alternatively, the controller 44 sends the real-time feed- 
back signal 38 to the management modules 1 on a single line 
as a time multiplexed analog signal, or on multiple lines as 
individual analog signals. 

Preferably, the traffic data contained within the real-time 
feedback signal 38 is a copy of the contents of the counters 
46,48. Accordingly, large amounts of storage space and 
processor resources for extensive post -processing are not 
required. Rather, any complexity involved in analyzing the 
traffic data (i.e., the counter contents) can be moved to the 
network packet management modules (the input scheduler 
16, the reorder manager 18 and the discard manager 20). 

Referring back to FIG. 1, the traffic analyzer 32-IS 
includes a control module 34-IS and memory 36-IS, and 
operates such circuitry to analyze basic traffic data stored 
within the real-time feedback signal 38. In one embodiment, 
the real-time feedback signal 38 is a digital signal that 
simply includes the contents of each counter 46 and 48 (see 
FIG. 2). For this embodiment, the traffic analyzer 32-IS 
keeps a clock to determine the change in time between 
receiving each set of counter contents. The traffic analyzer 
32-IS determines the total bit rate for the most recent set of 
transmitted packets from the most recent set of counter 
contents, the previous set of counter contents and the delta 
time as follows: 



Overall Bit Rate = 



most recent total bit count - previous total bit count 
time between most recent and previous total bit counts 
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Similarly, the bit rate for any particular packet class can be 
determined as follows: 
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most recent class bit count - previous class bit count 

Bit Rate For = . 

Particular t " ne ^ ,etween most rcc ent and previous class bit counts 

Packet Class 

Additionally, the percentage of bandwidth can be calculated 
for each packet class. Below is a calculation for the per- 
centage of video packets: 

number of video data packets counted 
percentage of = . 

video data packets numbcr of total P ackcts countcd 

Since traffic data analysis is preferably performed within the 
traffic analyzers 32, the traffic monitor 26 can be kept 
simple. Accordingly, less processor and memory resources 
are required for the traffic monitor 26 relative to conven- 
tional traffic monitoring devices that store large amounts of 
traffic data over extended periods of time (e.g., hours or even 
days) and which then must post-process the large amounts of 
traffic data. 

Nevertheless, more sophisticated monitoring devices are 
also suitable for the traffic monitor 26. For example, in one 
embodiment, the traffic monitor 26 counts bits rather than 
packets 14 in order to provide finer granularity of data. In 
this embodiment, over specified time intervals, each counter 
46 counts bits for a corresponding TOS class of traffic (e.g., 
for a particular QoS class) and the aggregate counter 48 
counts the total number of bits for all TOS classes. The 
transmission speed (i.e., the speed of the media) is used as 
a clock. The number of bits counted for each traffic class is 
then divided by the media speed multiplied by the time 
interval to determine the media utilization and rate infor- 
mation of each TOS class. This embodiment provides finer 
resolution than the earlier described packet counting 
embodiment. 

An example of a device that is capable of operating in this 
manner and that is suitable for the traffic monitor 26 is the 
Event Driven Interface (EDI) manufactured by International 
Business Machines of Armonk, New York. The EDI per- 
forms pattern recognition based upon a program defined by 
control vectors. In particular, the EDI receives a serial bit 
stream (provided by the output scheduler 24), and performs 
logical pattern recognition to produce signals as an output in 
response to the identification of specific, predefined patterns 
in the serial bit stream. 

Some details of the EDI and similar traffic monitoring 
techniques are described in U.S. Pat No. 5,365,514 
(Hershey, et al.), entitled "Event driven interface for a 
system for monitoring and controlling a data communica- 
tions network," the teachings of which are incorporated by 
reference herein in their entirety. Other similar traffic moni- 
toring techniques are described in U.S. Pat No. 5,375,070 
(Hershey, et al.), entitled "Information collection architec- 
ture and method for a data communications network," the 
teachings of which are incorporated by reference herein in 
their entirety. Additionally, similar traffic monitoring tech- 
niques are described in U.S. Pat No. 5,493,689 (Waclawsky, 
et al.), entitled "System for configuring an event driven 
interface including control blocks defining good loop loca- 
tions in a memory which represent detection of a charac- 
teristic pattern," the teachings of which are incorporated by 
reference herein in their entirety. Furthermore, similar traffic 
monitoring techniques are described in U.S. Pat. No, 5,586, 
266 (Hershey, et al.), entitled "System and method for 
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adaptive, active monitoring of a serial data stream having a 
characteristic pattern," the teachings of which are incorpo- 
rated by reference herein in their entirety. Still further, 
similar traffic monitoring techniques are described in U.S. 

5 Pat No. 5,615,135 (Waclawsky, et al), entitled "Event 
driven interface having a dynamically reconfigurable 
counter for monitoring a high speed data network according 
to changing traffic events," the teachings of which are 
incorporated by reference herein in their entirety. 

10 In one embodiment, the invention uses the flexibility and 
sophistication of the EDI and similar traffic monitors to 
enable the real-time feedback signal 38 to include custom- 
ized data. To take advantage of such features, the traffic 
analyzers 32 of the management modules (e.g., the traffic 

15 analyzer 32 -DM of the discard manager 20) are equiped to 
send a request signal 40 to the traffic analyzer 26 requesting 
customized data. 

Such a feature provides the invention with the ability to 
better determine the proper course of operation to improve 

20 throughput and the data communication device's ability to 
meet or exceed its QoS goals. Furthermore, the QoS goals 
may occasionally conflict giving rise to the potential for 
oscillating operation, i.e., the data communication device 
operating at one extreme to achieve one goal and then a 

25 different extreme to achieve a different goal, and so forth. 
Such operation is typically undesirable since substantial 
overhead is needed to shift between operating extremes. To 
prevent such operation from occurring, the management 
modules's abilities to request custom traffic data enable the 

30 data communications device 10 to achieve convergence of 
goals, namely a compromise that results in stable yet optimal 
non-oscillating operation. 
Management Modules 

Each of the network packet management modules (the 

35 input scheduler 16, the reorder manager 18 and the discard 
manager 20) has a set of module specific TOS goals (e.g., 
QoS goals), and uses the real-time feedback signal 38 to 
attain those goals. In particular, when the data communica- 
tions device 10 is in normal operation, each management 

40 module 16, 18, 20 performs a procedure 70 to attain its 
specific TOS goals, as will now be explained in further detail 
with reference to FIG. 4. 

In step 72, the management module initializes a set of 
control parameters according to a control algorithm. The 

45 control parameters are specific to the particular management 
module and selected to enable the module to attain a set of 
particular TOS goals. 

In step 74, the management module performs its module 
function based on the control parameters. The module 

so function is specific to the particular management module as 
well. 

In step 76, the management module checks whether it 
should continue to operate with real-time adjustments. For 
example, if the data communications device 10 determines 

55 that it should shutdown, the management module terminates 
or ends the procedure 70. Otherwise, the management 
module proceeds to step 78. 

In step 78, the management module obtains real-time 
feedback results based on the real-time feedback signal 38 

60 provided by the traffic monitor 26, In particular, the traffic 
analyzer 32 of the management module analyzes the traffic 
data contained within the real-time feedback signal 38 to 
generate the real-time feedback results. Preferably, the man- 
agement module generates customized results from the 

65 traffic data within the real-time feedback signal 38 by 
performing module-specific calculations using the more 
general network data contained within the real-time feed- 
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b ack signal 38. In the alternative, if the traffic monitor 2 6 has provided in the real-time feedback signal 38 to generate 

enough sophistication to provide the customized results customized results for the input scheduler 16. Alternatively, 

directly, the management module sends requests for the the input scheduler 16 sends a request signal 40 to the traffic 

results, and the real-time feedback signal is generated in monitor 26 to request traffic data in a customized form, and 

response to such requests. 5 the traffic monitor 26 responds with the customized results 

In step 80, the management module determines whether stored within the real-time feedback signal 38. 

an adjustment to its operation is needed. For example, the In step 80, the input scheduler 16 determines whether to 

management module may compare the generated network continue with the present queue assignments and the present 

traffic results to a set of particular TOS goals to determine queue sizes depending upon whether particular QoS goals 

whether the management module is achieving these TOS 10 for the input scheduler 16 have been achieved. For example, 

goals. If no adjustment is needed (e.g., if the QoS goals are the input scheduler 16 may have a QoS goal of providing 

achieved), step 80 proceeds back to step 74. If an adjustment 25% of the output scheduler's bandwidth to general data 

is needed (e.g., if the QoS goals are not achieved), step 80 packets. If the real-time feedback results indicate that the 

proceeds to step 82. data communications device 10 has achieved the QoS goals, 

In step 82, the management module adjusts the control 15 the input scheduler 16 proceeds back to step 74. Otherwise, 

parameters (initialized in step 72) according to the one or the input scheduler 16 proceeds to step 82. 

more algorithms based on the real-time feedback results. In step 82, the input scheduler 16 adjusts the control 

Such adjustments typically improve the data communica- parameters according to one or more algorithms and real- 

tions device's ability to attain the particular TOS goals for time feedback results in an attempt to achieve the QoS goals, 

the management module. Then, step 82 proceeds back to 20 For example, suppose the input scheduler 16 fails to achieve 

step 74. the goal of providing 25% of the output scheduler's band- 

When the data communications device 10 is in normal width to general data packets even though the queue 

operation, the management module may perform several assigned to general data packets is generally full and the 

iterations of the steps of procedure 70. Through each other queues are generally empty. In such a situation, the 

iteration, the management module ensures that the data 25 input scheduler 16 runs an algorithm on this traffic data and 

communications device 10 operates in such a manner that determines that the failure may be due to the discarding of 

the TOS goals are likely to be achieved. As the character- general data packets due to congestion at the output sched- 

istics of the outputted network traffic change (i.e., the uler 24 (resulting from high network traffic in the network 

packets 14 transmitted from the output scheduler 24), the 12). Accordingly, the algorithm of the input scheduler 16 

data communications device 10 dynamically alters its opera- 30 may direct the input scheduler 16 to increase the queue size 

tion to accommodate such changes. of the queue responsible for temporarily storing general data 

A further explanation will now be provided for each of the packets (e.g., queue 30-B) since buffering the general data 

different network packet management modules 16, 18, 20 packets, in contrast to discarding general data packets, 

beginning with the input scheduler 16. In particular, separate increases the likelihood that the packets will be transmitted 

examples are provided of each management module 16, 18, 35 successfully. 

20 in the context of a data communications device 10 that The input scheduler 16 then returns to step 74, and 

supports a variety of QoS classes (e.g., video, audio, general schedules newly arriving packets 14 in the queue structure 

data and best effort). 28 based on the adjusted control parameters. Over time, the 

Input Scheduler Example procedure 70 may loop through steps 74-82 several times 

In step 72, the input scheduler 16 initializes a set of 40 such that the input scheduler 16 changes its operation 
control parameters controlling the manner in which packets dynamically over time in response to variations in the 
are placed within the queue structure 28. In particular, the set network traffic passing through the data communications 
of control parameters assigns a particular packet class to device 10. For example, suppose that the network conges- 
each queue 30 and controls the size of each queue 30. By tion clears a few minutes later. At that time, the input 
way of example, packets 14 of the best effort class are 45 scheduler 16 may determine that the larger queue size is no 
assigned to queue 30- A of the queue structure 28. General longer necessary and reclaim some space in the memory 22. 
data packets are assigned to queue 30-B. Audio packets are In one embodiment, the input scheduler 16 determines 
assigned to queue 30-C. Video packets are assigned to queue whether a control parameter adjustment should be made 
30-D. The queue sizes can be set such that the queue (step 80) approximately every minute (60 seconds), 
structure 28 can store an equal number of best effort, general 50 Since such changes occur in an automated manner in 
data, audio and video packets. response to the real-time feedback signal 38, rather than in 

In step 74, the input scheduler 16 performs its function of response to human intervention (such as by a network 

scheduling packets 14 within the queue structure 28. For administrator) over extended and perhaps protracted periods 

example, as network packets 14 arrive at the data commu- of time, the input scheduler 16 provides for superior network 

nications device 10, the input scheduler 16 stores all packets 55 packet scheduling. In particular, the input scheduler 16 is 

of the best effort class in queue 30-A, all packets of the capable of adapting and adjusting its operation to short and 

general data class in queue 30-B, and so on. perhaps subtle changes in network traffic in time frames that 

In step 76, the input scheduler 16 determines whether it are orders of magnitude shorter than conventional tech- 
should continue scheduling network packets 14. For niques requiring either human intervention or techniques 
example, a shutdown signal received by the data commu- 60 that focus onlu on traffic arrival patterns from the network, 
nications device 10 may cause the input scheduler 16 to Such changes would go unnoticed by conventional tech- 
terminate its packet scheduling operation. niques that collect traffic data over extended time periods. 

In step 78, the input scheduler 16 receives customized Reorder Manager Example 

real-time feedback results that are based on traffic data A further explanation of the operation of the reorder 

accumulated by the traffic monitor 26. In particular, the 65 manager 18 in the context of QoS classes will now be 

traffic analyzer 32-IS (i.e., the controller 34-IS in conjunc- provided with reference to FIG. 4. In step 72, the reorder 

tion with the memory 36-IS) operates on general traffic data manager 18 initializes a set of control parameters which 



01/05/2004, EAST Version: 1.4.1 



US 6,4 

13 

control the order of the queues 30 within the queue structure 
28. As such, the control parameters effectively control the 
priority of QoS classes handled by the data communications 
device 10. By way of example, network packets of the best 
effort class initially are given the lowest priority and 
assigned to queue 30-A of the queue structure 28. General 
data packets initially are given the a higher priority and 
assigned to queue 30-B. Audio packets initially are given a 
higher priority and assigned to queue 30-C. Video packets 
initially are given the highest priority and assigned to queue 
30-D. 

In step 74, the reorder manager 18 orders the queues 30 
within the queue structure 28 based on the control param- 
eters initialized in step 72. For example, the reorder manager 
18 orders queue 30-D first to give the video QoS class the 
highest priority, followed by queue 30-C for the audio QoS 
class, queue 30-B for the general data QoS class, and queue 
30-A for the best effort QoS class. 

In step 76, the reorder manager 18 determines whether it 
should continue to order the queues 30. A shutdown signal 
received by the data communications device 10 would cause 
the reorder manager 18 to terminate its queue ordering 
operation. Otherwise, the reorder manager 18 proceeds to 
step 78. 

In step 78, the reorder manager 18 receives customized 
real-time feedback results that are based on traffic data 
monitored by the traffic monitor 26. In particular, the traffic 
analyzer 32-RM (i.e., the controller 34-RM in conjunction 
with the memory 36-RM) operates on general traffic data 
provided in the real-time feedback signal 38 to generate 
customized results for the reorder manager 18. Alternatively, 
the reorder manager 18 sends a request signal 40 to the 
traffic monitor 26 to request traffic data in a customized 
form, and the traffic monitor 26 responds with the custom- 
ized results stored within the real-time feedback signal 38. 

In step 80, the reorder manager 18 determines whether 
particular QoS goals for the reorder manager 18 have been 
achieved. For example, the reorder manager 18 may have a 
QoS goal of providing 25% of the output scheduler's 
bandwidth to general data packets. If the real-time feedback 
results indicate that the reorder manager 18 meets this goal, 
the reorder manager 18 proceeds to step 74. Otherwise, the 
reorder manager 18 proceeds to step 82. 

In step 82, the reorder manager 18 adjusts its control 
parameters according to one or more algorithms and the 
real-time feedback results. For example, the reorder man- 
ager 18 may use an anti -starvation algorithm to promote any 
QoS classes that are prevented from transmitting due to 
other QoS classes overutilizing the output sheduler 24. In 
this situation, the anti-starvation algorithm may reprioritize 
the queues 30, at least temporarily, to allow packets of the 
non-transmitting QoS class (i.e., the starved class) to trans- 
mit. 

As another example, in step 82, if the real -time feedback 
results indicate that 20% of the output scheduler's band- 
width is general data packets and a reorder manager algo- 
rithm indicates that 25% bandwidth for general data packets 
can be achieved by re-prioritizing the list of traffic classes 
such that, at least temporarily, general data is given a higher 
priority than audio packets, the reorder manager 18 adjusts 
the control parameters accordingly. That is, the reorder 
manager 18 swaps the priority of the general data QoS queue 
(queue 30-B) and the audio QoS queue (queue 30-C) on its 
prioritization list such that the general data QoS queue is 
given higher priority. Similarly, if the real-time feedback 
results indicate that only 5% of the output scheduler's 
bandwidth is general data packets, the reorder manager 
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algorithm may instruct the reorder manager 18 to take more 
drastic measures such as giving the audio QoS queue (queue 
30-C) a higher priority than the video QoS queue (queue 
30-D). 

5 The reorder manager 18 then returns to step 74, and 
schedules newly arriving packets 14 in the queue structure 
28 based on the adjusted control parameters. Over time, the 
procedure 70 may loop through steps 74-82 several times 
such that the reorder manager 18 changes its operation 
dynamically over time in response to variations ,in the 
network traffic passing through the data communications 
device 10. In one embodiment, the reorder manager 18 
determines whether a control parameter adjustment should 
be made (step 80) approximately every 5 to 10 seconds. 
Since such changes occur in response to a real-time feed- 

15 back signal rather than in response to human intervention 
(such as by a network administrator) over extended and 
perhaps protracted periods of time, the reorder manager 18 
provides superior reordering. In particular, the reorder man- 
ager 18 is capable of adapting and adjusting its operation to 

20 short and perhaps subtle changes in network traffic in time 
frames that are orders of magnitude shorter than conven- 
tional techniques requiring human intervention or rely on 
traffic arrival patterns into the data communications device 
from the network. 

25 Discard Manager Example 

A further explanation of the operation of the discard 
manager 20 will now be provided with reference to FIG. 4. 
In step 72, the discard manager 20 initializes a set of control 
parameters that control the discarding of network packets 14 

30 from the queue structure 28. By way of example, the control 
parameters direct the discard manager 20 to discard all best 
effort packets before discarding all other packets. 
Additionally, the control parameters direct the discard man- 
ager 20 to discard general data packets prior to discarding 

35 audio packets, and then to discard audio packets prior to 
discarding video packets. 

In step 74, the discard manager 20 discards packets from 
one or more of the queues 30 if any of the queues 30 become 
filled. For example, suppose that the best effort QoS queue 

40 (e.g., queue 30-A) becomes filled. In response, the discard 
manager 20 discards packets from the best effort queue 
(queue 30-A). 

In step 76, the discard manager 20 determines whether it 
should continue to operate. For example, a shutdown signal 
45 received by the data communications device 10 would cause 
the discard manager 20 to terminate its queue ordering 
operation. Otherwise, the discard manager 20 proceeds to 
step 78, 

In step 78, the discard manager 20 receives customized 

50 real-time feedback results that are based on traffic monitored 
by the traffic monitor 26. In particular, the traffic analyzer 
32-DM (i.e., the controller 34-DM in conjunction with the 
memory 36-DM) operates on general traffic data provided in 
the real-time feedback signal 38 to generate customized 

55 results for the discard manager 20. Alternatively, the discard 
manager 20 sends a request signal 40 to the traffic monitor 
26 to request traffic data in a customized form, and the traffic 
monitor 26 responds with the customizes results stored 
within the real-time feedback signal 38. 

60 In step 80, the discard manager 20 determines whether 
particular QoS goals for the discard manager 20 have been 
achieved. For example, the discard manager 20 may have a 
QoS goal of providing 30% of the output scheduler's 
bandwidth to video data packets. If the real-time feedback 

65 results indicate that the discard manager 20 meets this goal, 
the discard manager 20 proceeds to step 74. Otherwise, the 
discard manager 20 proceeds to step 82. 
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In step 82, the discard manager 18 adjusts its set of control 
parameters according to a discard algorithm and the real- 
time feedback results in signal 38 (see FIG. 1). For example, 
if the real-time feedback results indicate that only 25% of the 
output scheduler's bandwidth is video data packets, 5% s 
short of the QoS goal of 30% for video packet bandwidth, 
the discard manager 20 adjusts the control parameters such 
that some non-video packets are discarded to make more 
bandwidth available to video packets. By way of example, 
suppose that the discard algorithm determines that the 10 
discard manager 20 should discard packets from the queue 
assigned to receive best effort packets (queue 30- A) in an 
attempt to raise the video packet bandwidth above 30%. 
Accordingly, the discard manager 20 adjusts the control 
parameters to allow discarding of best effort packets from is 
the queue structure 28. Step 82 then proceeds back to step 
74. 

In step 74, the discard manager 20 discards best effort 
packets from the queue structure 28. The effect of such 
discarding will be sensed by the traffic monitor 26 and cause 20 
a change in the traffic data within the real-time feedback 
signal 38 which is sent to the discard manager 20. 
Accordingly, a feedback loop is formed that enables the 
discard manager 20 to dynamically control discarding of 
packets using the real-time feedback signal 38. In one 25 
embodiment, the discard manager 20 determines whether a 
control parameter adjustment should be made (step 80) 
approximately every second. No human intervention is 
required. 

Traffic Analyzer 30 

FIG. 5 shows a procedure 90 performed by each of the 
traffic analyzers 32-IS, 32-RM, and 32-DM demonstrating 
that traffic analyzer's ability to generate different types of 
performance measures (e.g., rate data) and optimality data 
based on the traffic data stored within the real-time feedback 35 
signal 38. In step 92, the traffic analyzer 32 receives traffic 
data within the real-time feedback signal 38. In step 94, the 
traffic analyzer 32 generates rate data based on the traffic 
data (e.g., rate data). In step 96, the traffic analyzer 32 
provides the rate data to the management module (e.g., the 40 
discard manager 20). 

Subsequent performance of procedure 90 by the same 
traffic analyzer 32 may generate a different type of perfor- 
mance measure or optimality data (e.g., step 94-B rather 
than step 94-A). Accordingly, different types of data can be 45 
provided to the management modules 16, 18, 20 for use in 
managing network packets 14. 

As a result, any management module of the data commu- 
nications device 10 may operate based on a variety of data 
and algorithms for scheduling, reordering and discarding. 50 
FIG. 6 shows a procedure 100 including such operation of 
the data communications device 10. In step 102-1, a par- 
ticular management module 16, 18, 20 of the data commu- 
nications device 10 performs a module function based on a 
first type of data (e.g., the discard manager 20 discards 55 
packets 14 based on rate data). In step 102-2, that manage- 
ment module performs a module function based on a second 
type of data that is different than the first type of data (e.g., 
the discard manager 20 discards packets 14 based on overall 
throughput). In step 102-N, the management module per- 60 
forms a module function based on another type of data (e.g., 
the discard manager 20 discards packets 14 based on per- 
centage bandwidth or the number of contiguous packets of 
a particular type seen by the traffic monitor 26). Accordingly, 
the management modules 16, 18, 20 of the data communi- 65 
cations device 10 have the flexibility and dynamic operation 
to optimally manage packets. 



FIG. 7 shows a different embodiment of the invention 
device than that shown in FIG. 1. In particular, FIG. 7 shows 
a data communications device 110 that includes a central 
traffic analyzer 122 for analyzing traffic data stored within 
the real-time feedback signal 38. The central traffic analyzer 
122 includes a control module 124 and memory 126. The 
central traffic analyzer 122 operates to provide traffic data in 
a manner similar to the traffic analyzers 32 of FIG. 1. 
However, the centralization of the traffic analyzer 122 pro- 
vides a benefit of reducing hardware since the centralized 
circuitry can be shared (e.g., in a multiplexed manner) 
between the various management modules. 

For either the data communications device 10 (see FIG. 1) 
or the data communications device 110 (FIG. 7), a real-time 
feedback signal, containing an immediate and up-to-date 
analysis of network traffic data, is used to enable the device 
10, 110 to make dynamic adjustments. Accordingly, such 
adjustments are based on current traffic conditions rather 
than out-dated conditions. This allows the invention devices 
to make adjustments that are superior to conventional adjust- 
ment techniques that use traffic data collected over extended 
periods of time such as hours or even days. Furthermore, no 
human intervention is required to make the adjustments for 
the invention devices. That is, such adjustments are made in 
an automatic and routine manner alleviating the need for 
human intervention. 

EQUIVALENTS 

While this invention has been particularly shown and 
described with references to preferred embodiments thereof, 
it will be understood by those skilled in the art that various 
changes in form and details may be made therein without 
departing from the spirit and scope of the invention as 
defined by the appended claims. 

For example, it should be understood that the above- 
discussed invention data communications devices can be 
any type of network related device that receives and trans- 
mits data packets. In particular, the data communications 
devices 10, 110 can be routers, bridges, switches, access 
servers, gateways, hubs, proxy servers, repeaters, and so 
forth which exchange data over an interconnection of data 
links. The data links may be physical cables (e.g., electrical 
or fiber optic connections) or wireless communication 
mechanisms (e.g., cellular telephony equipment). Such data 
communications devices can be general purpose computers 
such as personal computers, workstations, minicomputers, 
mainframes and the like running specialized network 
software, or specialized hardware such as cellular base 
stations, web-site kiosks, facsimile or e-mail servers, video 
servers, and so forth. 

In the context of devices with multiple inputs or outputs, 
it should be understood that the elements shown in FIGS. 1 
and 7 apply to individual outputs of such devices. For 
example, for a router with multiple inputs and outputs, the 
elements of FIG. 1 illustrate the portions of the router that 
operate for a particular output of the router. Other outputs of 
the router would have similar elements or may share a 
centralized component. 

Additionally, the data communications devices of the 
invention can be used with various network protocols and 
with various network types. In particular, networks environ- 
ments having data rates such as fractional Tl, Tl, El or 
higher or lower, are suitable for the invention. 

Furthermore, various media are suitable for carrying the 
real-time feedback signal 38 (see FIGS. 1 and 7). The signal 
38 may be digital, analog, modulated (AM or FM) or spread 
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spectrum wireless (e.g., CDMA). Additionally, the media 
can be electrical, optical or wireless. 

Moreover, the traffic analyzer 32, 122 and/or the traffic 
monitor 26 may be external to the data communications 
device 10, 110. That is, a conventional data communications 
device and a conventional traffic monitor can be adapted 
such that the traffic monitor provides a real-time feedback 
signal rather than simple data for storage and post- 
processing. Similarly, a conventional data communications 
device can be adapted to receive real-time results as input. 
The traffic analyzer then analyzes the traffic data contained 
within the real-time signal and generates real-time results 
that enable the data communications device to make 
dynamic adjustments. Accordingly, human intervention is 
not required to make adjustments, and such adjustments are 
made automatically in a timelier manner. 

Additionally, it should be understood that the data com- 
munications device may include other management modules 
(e.g., other modules in addition to the input scheduler 16, the 
reorder manager 18 and the discard manager 20), and that 
such modules may operate according to one or more algo- 
rithms using the real-time feedback results derived from the 
real-time feedback signal as an input. Accordingly, adjust- 
ments to the operation of the modules are based, at least 
partially, on the real-time feedback signal. 

It should be understood that it is unnecessary for each 
management module to operate according to the real-time 
feedback signal. Rather, at least one management module 
operates according to the real-time feedback signal. Some or 
all of the management modules may use conventional algo- 
rithms to determine operation. However, at least one of the 
management modules uses an algorithm that takes the 
generated real-time feedback data as an input. To reduce the 
complexity of having to create new algorithms, conventional 
algorithms can be used where a normally non-real-time 
input is replaced with the real-time feedback results. 

Furthermore, it should be understood that the real-time 
feedback signal 38 is preferably sent automatically from the 
traffic monitor 26. In this situation, there is no need for the 
traffic monitor 26 to receive a request signal 40. 

As an alternative, if the traffic monitor 26 is a sophisti- 
cated device capable of providing customized results, the 
traffic monitor 26 waits for the request signal 40 to identify 
a particular type customized result and then sends the 
real-time feedback signal 38 in response to the request 40. 
In this situation, the requests 40 are regular in nature such 
that the real-time feedback signal 38 is provided routinely 
enabling the data communications device to maintain packet 
management under dynamic control. 

Furthermore, it should be understood that the procedure 
70 (see FIG. 4) can be modified such that the control 
parameters of the management module are adjusted regard- 
less of whether the data communications device presently 
achieves its TOS requirements (e.g., QoS goals). 
Accordingly, performance improvements are attempted con- 
tinuously. 

Additionally, it should be understood that classes other 
than QoS classes are suitable TOS for the invention. For 
example, dedicated TOS classes can be established for 
particular events such as a scheduled point-to-point audio/ 
video conference or a scheduled pay-per-view event. In such 
situations, data communication devices along a path of the 
network 12 operate to provide a customized TOS between 
the source and destination for each event. 

Furthermore, it should be understood that the operations 
of the input scheduler 16, the reorder manager 18, the 
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discard manager 20, and perhaps other modules using the 
real-time feedback signal 38, can be based on a variety of 
metrics. In one embodiment, the real -time feedback signal 
38 indicates, and these modules use, as metrics, at least one 

5 of a maximum packet size for each of the multiple packet 
classes, a minimum packet size for each of the multiple 
packet classes, a mean packet size for each of the multiple 
packet classes, a maximum packet size for all of the multiple 
packet classes, a minimum packet size for all of the multiple 
packet classes, a mean packet size for all of the multiple 
packet classes, a maximum number of contiguous bits for 
each of the multiple packet classes, a minimum number of 
contiguous bits for each of the multiple packet classes, a 
mean number of contiguous bits for each of the multiple 
packet classes, a maximum number of contiguous bits for all 

15 of the multiple packet classes, a minimum number of 
contiguous bits for all of the multiple packet classes, and a 
mean number of contiguous bits for all of the multiple 
packet classes. Other similar traffic-related metrics can be 
used as well, and are intended to be within the scope of the 

20 invention. 

What is claimed is: 

1. A method for managing packets in a data communica- 
tions device having a memory, the method comprising the 
steps of: 

25 transmitting an initial set of packets from the data com- 
munications device; 
monitoring transmission of the initial set of the packets 
from the data communications device, and providing a 
real-time feedback signal indicating transmission infor- 
30 mation regarding the initial set of packets; 

manipulating a new set of packets within the memory of 
the data communications device based on the real-time 
feedback signal; and 
transmitting the new set of packets from the data com- 
35 munications device based on how the new set of 
packets was manipulated within the memory of the data 
communications device. 

2. The method of claim 1 wherein each packet belongs to 
one of multiple packet classes, and wherein the step of 

40 monitoring and providing includes the step of: 

generating the real-time feedback signal to indicate trans- 
mission levels of the multiple packet classes for the 
initial set of packets. 

3. The method of claim 2 wherein the memory of the data 
45 communications device stores a queue structure, and 

wherein the step of manipulating includes the step of: 
scheduling a packet of the new set of packets in the queue 
structure based on the transmission levels of the mul- 
tiple packet classes for the initial set of packets, as 
50 indicated by the real-time feedback signal. 

4. The method of claim 2 wherein the memory of the data 
communications device stores a queue structure, and 
wherein the step of manipulating includes the step of: 

reordering queues within the queue structure when the 
55 transmission levels of the multiple packet classes for 
the initial set of packets, as indicated by the real-time 
feedback signal, cause the data communications device 
to detect a reorder condition. 

5. The method of claim 2 wherein the memory of the data 
60 communications device stores a queue structure, and 

wherein the step of manipulating includes the step of: 
discarding a packet of the new set of packets from the 
queue structure when the transmission levels of the 
multiple packet classes for the initial set of packets, as 
65 indicated by the real-time feedback signal, cause the 
data communications device to detect a discard condi- 
tion. 
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6. The method of claim 2 wherein the memory of the data 12. The data communications device of claim 11 wherein 
communications device stores a queue structure, and each packet belongs to one of multiple packet classes, and 
wherein the step of manipulating includes the steps of: wherein the traffic monitor includes: 

scheduling each of the new set of packets in the queue a controller that generates the real-time feedback signal to 

structure based on the transmission levels of the mul- 5 indicate transmission levels of the multiple packet 

tiple packet classes for the initial set of packets, as classes for packets transmitted from the storage and 

indicated by the real-time feedback signal; transmission circuit 

' ^ 13. The data communications device of claim 12 wherein 

reordering queues of the queue structure when the trans- the storage and transmiss i 0 n circuit includes a memory that 

mission levels of the multiple packet classes for the stores a queue structure, and wherein the control circuit 

initial set of packets, as indicated by the real-time includes: 

feedback signal, cause the data communications device an m p Ut scheduler having a first input that receives 

to detect a reorder condition; and packets, a second input that receives the real-time 

discarding a packet of the new set of packets from the feedback signal, and an output that schedules the 

queue structure when the transmission levels of the received packets in the queue structure based on the 

multiple packet classes for the initial set of packets, as transmission levels of the multiple packet classes, as 

indicated by the real-time feedback signal, cause the indicated by the real-time feedback signal, 

data communications device to detect a discard condi- 14. The data communications device of claim 12 wherein 

tion. the storage and transmission circuit includes a memory that 

7. The method of claim 2 wherein each packet includes a 2Q stores a queue structure, and wherein the control circuit 
bit pattern indicative of one of the multiple packet classes, includes: 

and wherein the step of monitoring and providing includes a reorder manager having an input that receives the 

the step of: real-time feedback signal, and an output that reorders 

sampling packets from the initial set of packets; q ueues within the <l ueue structure when the transmis- 

recognizing, for each sampled packet, a bit pattern of that 25 |> ion u teveJs 1 of lhe raul 1 t jP le 1 P^ket classes, as indicated 

packet, and updating a set of data structures based on b V the real -] ime feedba <* cause tne reorder 

the recognized bit pattern of that packet, the data ™ nag f r l ° deteCl a re ° rde ' condltl ° n - . „ u . 

structures respectively corresponding to the multiple 15. The data commumcations device of claim 12 wherein 

k t classes* and storage and transmission circuit includes a memory that 

. ' , . p t • i . . stores a queue structure, and wherein the control circuit 
generating the real-time feedback signal based on the 30 mc j udes . 

updated set of data structures such that the real-time ' , . . . 

feedback signal is indicative of the transmission levels a dis f rd ^nager havmg an input that ^receives he 

of the multiple packet classes for the initial sel of feedback sl S na1 ' and an ° ut P"' lhat dlscards a 

u t packet from the queue structure when the transmission 

8. Tte method of claim 7 wherein the real-time feedback 35 lev f ls ° f the «™ !»P le P a f eI classes as indicated by the 

, . , ,. t - « p .t , i t real-time feedback signal, cause the discard manager to 

signal indicates a bit count for each of the multiple packet » . ' & 

classes, and a total bit count; and wherein the method further , .^T 1 , 4 discard condlUon * . . 

com rises the step of* e communications device of claim 12 wherein 

comprises p ^ e storage and transmission circuit includes a memory that 

providing a bit rate for each ofthe multiple packet classes stores a structure , and wherein the control circuit 
based on the bit count for each of the multiple packet w includes* 

classes and the total bit count such that the new set of . ' , , . , . « . « ♦ *i. ♦ 

. , *uu**.p u an in P ut scheduler having a first input that receives 

packets are manipulated based on the b,t rate for each J * ^ ^ 

of the multiple packet elates. . feedback signal, and an output that schedules the 

9. The method of claim 2, further composing the step or: . , ~ t . . * . u j *u 

* . *. 6 45 received packets in the queue structure based on the 

generating, prior to the step of monitoring and providing, transmission levels of the multiple packet classes, as 

a request signal for information regarding the transmis- indicated b the reaMimc feedback signal; 

sion levels of the multiple packet classes for the initial a reorder managef haying ^ ^ ^ ^ 

+J^}n- 0t P a( J e | s ' . . real-time feedback signal, and an output that reorders 

10. The method of claim 9 wherein the step of momtonng of ^ % {mc{UTQ when lhe transraission 
and providing includes the step of: leyels of ^ muhiple packe( ^ m ^ Xq6 by (he 

generating the real-time feedback signal in response to the real-time feedback signal, cause the reorder manager to 

request signal. detect a rcorc ier condition; and 

11. A data communications device, comprising: a discafd manager haying an input ^ receiyes the 
a storage and transmission circuit that stores and transmits 5S real-time feedback signal, and an output that discards a 

packets; packet from the queue structure when the transmission 

a traffic monitor, coupled to the storage and transmission levels of the multiple packet classes, as indicated by the 

circuit, that monitors packet transmissions from the real-time feedback signal, cause the discard manager to 

storage and transmission circuit, and generates a real- detect a discard condition. 

time feedback signal indicating packet transmission 60 17. The data communications device of claim 16 wherein 

information; and the input scheduler, the reorder manager and the discard 

a control circuit, coupled to the storage and transmission manager use respective instances of the real-time feedback 

circuit and the traffic monitor, that manipulates packets signal to operate asynchronously relative to each other, 

within the storage and transraission circuit based on the 18. The data communications device of claim 16 wherein 
real-time feedback signal, the storage and transmission 65 the input scheduler, the reorder manager and the discard 

circuit transmitting packets based on how the packets manager use a same instance of the real-time feedback 

are manipulated by the control circuit. signal when in operation. 
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19. The data communications device of claim 12 wherein- 
each packet includes a bit pattern indicative of one of the 
multiple packet classes, and wherein the traffic monitor 
includes: 

a pattern recognizer that (i) samples packets transmitted 
from the storage and transmission circuit, and (ii) 
recognizes, for each sampled packet, a bit pattern of 
that packet; and 

a controller, coupled to the pattern recognizer, that (i) 
updates, for each sampled packet, a set of data struc- 
tures based on the recognized bit pattern of that packet, 
the data structures respectively corresponding to the 
multiple packet classes, and (ii) generates the real-time 
feedback signal based on the updated set of data 
structures such that the real-time feedback signal is 
indicative of the transmission levels of the multiple 
packet classes. 

20. The data communications device of claim 19 wherein 
the real-time feedback signal indicates a bit count for each 
of the multiple packet classes, and a total bit count; and 
wherein the control circuit includes: 

a traffic analyzer that receives the real-time feedback 
signal and provides a bit rate for each of the multiple 
packet classes based on the bit count for each of the 
multiple packet classes and the total bit count such that 
packets are manipulated within the storage and trans- 
mission circuit based on the bit rate for each of the 
multiple packet classes. 

21. The data communications device of claim 12 wherein 
the real-time feedback signal indicates, as metrics, at least 
one of a maximum packet size for each of the multiple 
packet classes, a minimum packet size for each of the 
multiple packet classes, a mean packet size for each of the 
multiple packet classes, a maximum packet size for all of the 
multiple packet classes, a minimum packet size for all of the 
multiple packet classes, a mean packet size for all of the 
multiple packet classes, a maximum number of contiguous 
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20 



25 



30 



35 



bits for each of the multiple packet classes, a minimum 
number of contiguous bits for each of the multiple packet 
classes, a mean number of contiguous bits for each of the 
multiple packet classes, a maximum number of contiguous 
bits for all of the multiple packet classes, a minimum 
number of contiguous bits for all of the multiple packet 
classes, and a mean number of contiguous bits for all of the 
multiple packet classes. 

22. The data communications device of claim 12 wherein 
the control circuit includes: 

a control module that generates a request signal for 
information regarding the transmission levels of the 
multiple packet classes. 

23. The data communications device of claim 22 wherein 
the traffic monitor includes: 

a controller having an input that receives the request 
signal, and an output that provides the real-time feed- 
back signal in response to the request signal. 

24. The method of claim 1 wherein the step of providing 
a real-time feedback signal further includes the step of 
generating customized data to send as said feedback signal. 

25. The method of claim 24 wherein said data commu- 
nications device has a plurality of management functions 
and said step of generating customized data includes the step 
of generating data customized to a particular management 
function. 

26. The method of claim 24 wherein said step of gener- 
ating customized data further includes generating data cus- 
tomized to achieve a type of service goal. 

27. The data communications device of claim 11 further 
comprising a plurality of management modules, each said 
management module having a particular data management 
function, and wherein the traffic monitor further includes a 
controller that generates a real-time feedback signal of 
customized data, said data customized to the particular 
function of one of said management modules. 
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